Eric Blake <[EMAIL PROTECTED]> wrote:
> According to Eric Blake on 1/17/2006 11:05 AM:
>>
>> The problem is that tcsh 6.14.00 treats LS_COLORS as a magic
>> environment variable, also parsing it for its own use in the
>> tcsh builtin ls-F. This means that coreutils dircolors, when given
>> an SUID
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Jim Meyering on 1/20/2006 2:38 AM:
>
> Thanks, but won't that also silence a legitimate warning about a mistyped
> value? I'd rather avoid emitting code that discards all stderr output.
No, my patch does not silence stderr during dircol
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Jim Meyering on 1/20/2006 6:44 AM:
>
> Ok. Granted that dircolors or tcsh needs to be fixed,
> I'm reluctant to make such a change to dircolors in order
> to work around what I see as overly-strict parsing on tcsh's part.
> Why not inves
Eric Blake <[EMAIL PROTECTED]> wrote:
> According to Jim Meyering on 1/20/2006 2:38 AM:
>>
>> Thanks, but won't that also silence a legitimate warning about a mistyped
>> value? I'd rather avoid emitting code that discards all stderr output.
>
> No, my patch does not silence stderr during dircolor
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
There are currently two competing uses of d_ino semantics in coreutils:
lib/backupfile.c assumes that if d_ino is ever 0, (captured by the macro
REAL_DIR_ENTRY, which is always non-zero on platforms without d_ino), that
readdir() returned an invalid e