Re: dircolors generates "uknown colorls variable su"

2006-01-20 Thread Jim Meyering
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

Re: dircolors generates "uknown colorls variable su"

2006-01-20 Thread Eric Blake
-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

Re: dircolors generates "uknown colorls variable su"

2006-01-20 Thread Eric Blake
-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

Re: dircolors generates "uknown colorls variable su"

2006-01-20 Thread Jim Meyering
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

question on d_ino semantics

2006-01-20 Thread Eric Blake
-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