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
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
-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
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 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 S