Re: dircolors generates "uknown colorls variable su"

[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 dircolors, only during the
eval afterwards (after all, it is a warning from tcsh during the eval, and
not from the execution of dircolors, that is annoying).  For example, even
with my patch applied:

$ echo foo | src/dircolors --csh -
dircolors: -:1: invalid line;  missing second token
$ eval "`echo foo | src/dircolors --csh -`"
dircolors: -:1: invalid line;  missing second token

That is because dircolors does not output anything to stdout on error, so
the eval never sees the redirection unless dircolors was successful.

> Instead, we can suggest that affected tcsh users just change the way
> they invoke eval so as to divert stderr themselves, e.g., like this:
> 
>   eval `dircolors -c`' >& /dev/null'

That is worse than doing it ourselves in dircolors, because it wrongly
assumes that dircolors will succeed.  It is a tcsh syntax error to eval an
empty redirection, which is what you have done if dircolors fails.  Also,
you should be encouraging double quotes, to avoid file name expansion of
the text resulting from ``.  An example from unpatched dircolors:

$ eval "`echo foo | dircolors --csh -`"' >& /dev/null'
dircolors: -:1: invalid line;  missing second token
Invalid null command.

The only thing that my patch doesn't control is the exit status of the
setenv embedded in the eval, and thus the overall exit status of the eval.
 tcsh sets $status to 1 instead of 0 if it printed a warning during
setenv, even though the setenv succeeds.

$ echo $LS_COLORS

$ setenv LS_COLORS 'su=37;41:'
Unknown colorls variable `su'.
$ echo $status
1
$ echo $LS_COLORS
su=37;41:

But I don't see a reasonable workaround for that, even if I did feel
comfortable changing return status, thanks to this bug in tcsh behavior:

$ setenv LS_COLORS ''
$ eval "setenv LS_COLORS 'su=37;41:' >& /dev/null"' ; echo hi ; echo $status'
hi
0
$ echo $status
1
$ eval "setenv LS_COLORS 'su=37;41:' >& /dev/null"' ; (exit 3) ; echo $status'
3
$ echo $status
1

Note that the overall $status after the eval remains at 1 from the setenv,
even though the echo hi or (exit 3) subsequently took place and
successfully altered $status within the context of the eval!

So the current status of my patch, when dircolors succeeds, is:

$ setenv LS_COLORS ''
$ echo SETUID '37;41' | src/dircolors --csh -
setenv LS_COLORS 'su=37;41:' >&/dev/null
$ eval "`echo SETUID '37;41' | src/dircolors --csh -`"
$ echo $status
1
$ echo $LS_COLORS
su=37;41:

- --
Life is short - so eat dessert first!

Eric Blake             address@hidden
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFD0Oab84KuGfSFAYARAs8WAKDFQpsYBp2Z+fWDMtdz4NFbbjW+iwCeNXua
munGoCdx/vkJjk7UsQQbHZo=
=IcTS
-----END PGP SIGNATURE-----