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

[Micah Cowan]

Lenny Domnitser wrote:
> On 6/13/07, Bob Proulx <address@hidden> wrote:
>> Improving this seems like a reasonable enhancement.
> 
> If you think changing the behavior of --color=auto will break things,
> I can do --color=smart, i.e. the TERMinal is not dumb.

Given that "dumb" isn't the only terminal type that doesn't support
color, and that dircolors ostensibly knows (non-comprehensively) which
ones do, I'd still vote for letting dircolors do the term detection
(that it already does), and have ls handle a set-but-empty LS_COLORS
accordingly.

For my part, I'm having a hard time envisioning any problems that could
be caused by using --color=auto for this; at least, exporting an empty
LS_COLORS when one means for ls to rely on its default color settings
seems an unnatural idiom: leaving LS_COLORS unset (for instance, by
neglecting to evaluate dircolors' output) seems a much more natural
idiom, and I would hope that's how people who want the defaults are
already doing it.

Additionally, if there are some people who are using the method that
will become broken, it will be easy to fix, and will not cause any loss
in functionality or breakage elsewhere, since it is inconceivable that
scripts parsing ls's output would be relying upon ls to output some
particular color sequences (or, even any color sequences).

-- 
Micah J. Cowan
Programmer, musician, typesetting enthusiast, gamer...
http://micah.cowan.name/