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. Bob _______________________________________________ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
