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 _______________________________________________ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils