|
From: | Linda Walsh |
Subject: | Re: the `--color' option of `ls' shadows the shortcut evaluation scheme of `&&' and `||' |
Date: | Tue, 12 Feb 2008 18:24:55 -0800 |
User-agent: | Thunderbird 2.0.0.9 (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? -l
[Prev in Thread] | Current Thread | [Next in Thread] |