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

[Linda Walsh]

Eric Blake wrote:
> 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).
----
        FWIW, I commonly use --color to turn color back on.
My usage:  I list a directory and it scrolls off screen.  So I redo
it with "|more" appended -- and then I get unhappy because I don't get
the same output I just looked at now that I've added a "paging" option,
so when color is helping sort out what is what, I re-edit again to:
ls --color|more... (my more is aliased to less, FYI).

        Having to specify "--color=always"...well that's just more
torture -- I have --color="auto" in my LS_OPTIONS...(or the alias,
forget which sometimes...).

        That's the only time I really want color "no matter what the
output", which is why I specify "color=auto".  I or perhaps someone else
might find it disconcerting to type:
"ls --color|more" and get no color -- what's the point of specifying
--color on the command line if it doesn't turn on color?

-l