[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: the `--color' option of `ls' shadows the shortcut evaluation scheme
Re: the `--color' option of `ls' shadows the shortcut evaluation scheme of `&&' and `||'
Tue, 12 Feb 2008 18:24:55 -0800
Thunderbird 220.127.116.11 (Windows/20071031)
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?