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

[Lenny Domnitser]

On 6/13/07, Bob Proulx <address@hidden> wrote:
> I don't understand.  That snippet you show works perfectly for me.  I
> am also an emacs user and the above configures perfectly for me within
> an emacs shell.  Therefore I don't understand what problem you are
> reporting.  Does the above not configure things for you properly?  Is
> there a problem with it?

It works fine, but it seems that it's a workaround for behavior ls
could have. The only reason I even noticed the 'bug' was that I
recently got new account on a system that didn't automatically give me
a nice .bashrc. I aliased ls to ls --color=auto, saw that Emacs didn't
like it, looked into the problem, and fixed my .bashrc.

Clearly a workaround does exist today, but I think that the problem is
in ls's domain, not bash's. Then again, it depends on what 'auto'
means. I figured auto meant "color when you can".

On 6/13/07, Andreas Schwab <address@hidden> wrote:
> The value of TERM has no influence on the color output, only LS_COLORS
> does, which is produced by dircolors (which does check TERM).  The
> option --color=auto is synonymous to --color=tty, it only matters
> whether the output is a tty.  If you don't want any colorization you
> need to unset LS_COLORS.

Yes, currently this is true, but that doesn't necessarily mean that
can't change. I did ask if the problem was in scope, though, because I
thought maybe people wanted 'auto' to mean only 'tty'.