Re: ls should not color output when --color=auto is used in environment TERM=dumb

[Micah Cowan]

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...
http://micah.cowan.name/