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