[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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 (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?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]