[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ls should not color output when --color=auto is used in environment
Re: ls should not color output when --color=auto is used in environment TERM=dumb
Wed, 13 Jun 2007 12:20:43 -0700
Thunderbird 22.214.171.124 (X11/20070604)
Bob Proulx wrote:
> Lenny Domnitser wrote:
>> It works fine, but it seems that it's a workaround for behavior ls
>> could have.
> Since ls already has so very many features adding more features
> requires a higher "activation energy" than adding features for other
> commands. For something conceptually very simple the ls command has
> become a very heavy application.
I would expect virtually every application that sends special terminal
control sequences (such as those used for coloring) to respect the TERM
variable and relevant terminal databases; it's just good manners.
OTOH, making /bin/ls rely on ncurses is obviously be a bad thing.
dircolors, OTOH, already /has/ its own terminal database built-in, which
can be adjusted by passing it files. And, in fact, dircolors will give
"LS_COLORS=''" if TERM=dumb, since it recognizes that it's not a color
terminal (or more accurately, fails to recognize it as a color terminal
in its database).
It seems to me, then, that ls should never colorize in the case that
LS_COLORS is /set/, but has a null value. Then the proper thing to do in
a .bashrc is to simply ensure that dircolors' output is eval'd before
invocation of a colorizing ls, and let dircolors/ls just DTRT.
Micah J. Cowan
Programmer, musician, typesetting enthusiast, gamer...