On 6/13/07, Bob Proulx <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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'. _______________________________________________ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
