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

[Bob Proulx]

Day wrote:
> I found this bug when I tried a tiny script which checks a directory
> is empty or not.
> 
>  [ "$(ls -A ./dir)" ] && echo "Not Empty" || echo "Empty"

So far so good.

> After `mkdir ./dir' and without adding anything into ./dir, run the
> script, the echoed message is "Empty". But when adding the `--color'
> option to `ls',

The --color option forces color codes on.  You wanted to use
'ls --color=auto' instead.

>  [ "$(ls -A --color ./dir)" ] && echo "Not Empty" || echo "Empty"

Using --color=auto allows ls to selectively turn color on or off
depending upon whether the output is a tty device or not.  That is the
right option for you to use instead of --color which is the same as
saying --color=always.

Obviously you don't want to use any --color* options there at all.
But I assume this is reduced from a larger test case where if seen in
the real case would make more sense.

> the echoed message is always "Not Empty", regardless of the fact
> that ./dir is actually EMPTY. Below is the tested result.

Although I think it is a little strange that 'ls --color=always' does
output terminal initialization codes when there is nothing to list I
don't think this can be catagorized as a bug when color has been
forced on manually.  This doesn't happen with --color=auto for
instance.

>  [ "$(ls -A --color ./dir)" ] && echo "Not Empty" || echo "Empty"

How did you happen to run into using 'ls --color' in a test such as
this?  That seems an unfortunate option choice there.  I recommend not
using --color there.  But obviously you already thought of that and so
I have to ask what you were doing that caused it to be there?  Why not
simply avoid saying anything there?  Why not simply use 'ls' without
color?  Could you say a few more words about how you came about this
problem?

Thanks
Bob