[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 11:36:17 -0600
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.
> 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.
I think my opposition is based upon the calling of this a bug when it
did exactly what you told it to do and it behaved as documented. :-/
> 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".
I prefer the configurability that the shell provides. Using the shell
makes this type of configuration control accessible to a large number
of people. Hard coding behavior in source code restricts people to
selecting one of the predefined behaviors. Therefore when practical I
prefer to see the configuration done in the more user accessable text
configuration world rather than in the source code world.
However I am not opposed to something like --color=term
(--color=autoterm ?) meaning based upon the TERM setting and also
based upon output being a tty device. That seems safe and easy
enough. Changing the behavior of the existing option seems more
likely to annoy people who have come to rely upon the previous
behavior. But I could be convinced otherwise if people thought that
it really did not matter in this case.
> 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'.
Improving this seems like a reasonable enhancement.