Re: the `--color' option of `ls' shadows the shortcut evaluation scheme of `&&' and `||'

[Eric Blake]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

According to Day on 2/11/2008 8:35 PM:
|
|  [ "$(ls -A --color ./dir)" ] && echo "Not Empty" || echo "Empty"
|
| the echoed message is always "Not Empty", regardless of the fact that
./dir is actually EMPTY. Below is the tested result.

Thanks for the report.  However, this is not necessarily a bug.  By
itself, --color is documented to mean --color=always, in which case ls
outputs command sequences to initialize and restore colors back to normal:

$ ls -A --color | od -tx1z
0000000 1b 5b 30 6d 1b 5b 6d                             >.[0m.[m<
0000007

And since that is output (even though it does not show up on the
terminal), the string is non-empty, hence the result of the [] test.  You
really want the color output to be supressed in this context (in $()
command substitution, the output is not a terminal, so color escape
sequences don't normally make sense to the downstream client), so you
should consider using --color=auto instead:

$ ls -A --color=auto | od -tx1z
0000000

It may be worth considering a patch to coreutils, such that plain --color
implies --color=auto rather than --color=always.  For example, this would
match how 'git config' reacts when interpreting color options (where
'auto' and 'true' are synonyms, and 'always' must be explicit).

It may also be worth a patch to ls to omit color sequences altogether if
there is no other output, although this may be more difficult to code
and/or justify.

- --
Don't work too hard, make some time for fun as well!

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

iD8DBQFHsSpu84KuGfSFAYARAtC2AJ9tkXl1dAXlU9JcXiAOq7B6Te7I5ACdEL5G
tbFOIuLMuC30mMwqXvLfsVE=
=3aQY
-----END PGP SIGNATURE-----