Red Hat Bugzilla – Bug 38370
ls should not use --color=tty unless .dircolors is present
Last modified: 2007-04-18 12:32:54 EDT
From Bugzilla Helper:
User-Agent: Mozilla/4.76 [en] (X11; U; Linux 2.2.18 i686)
Redhat imposes a default --color=tty option alias on ls commands by
default. That is
undesireable. You can't predict what foreground and background colors the
going to be using and therefore many default color combinations will be
Also, this behavior is imposed upon a user in the global /etc/profile.d
the user would want this or not. That is not desireable.
Redhat has configured it to be possible to disable colorization by adding a
file in the user's home directory and configuring this to be "COLOR none"
that means that if you don't want this breakage you have to ask to get
That is also undesireable. It would be best to have normal ls behavior by
turn colorization on if and only if the user requests it, possibly by
having the .dircolors
file in their home directory, as before. That would maintain compatibility
with all users
that have specified colors to be used but would prevent this breakage when
it is not
desired to have colorization.
At the very least the files in /etc/profile.d should be separated into an
package such that it could be individually removed or avoided. In the
Steps to Reproduce:
1. log in
Actual Results: The /etc/profile.d/colorls.sh file was sourced and aliases
for ls defined which
included the --color=tty option.
Expected Results: I expected ls to behave in the traditional manor WITHOUT
color. This is
also the default GNU behavior. Only Redhat has this imposed breakage.
It's not a bug, it's a feature, because most users find the colorized output
If you don't like it, echo "unalias ls" >>~/.bashrc