From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20010917
Description of problem:
Partial update from rawhide (setup and bush) applied to 7.1 turns of the
"lights". ls becomes boringly monochrome.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. setup + bush update
2. colorful ls is no more
Sorry, forgot to add. Root still has colors, that's regular users who lose them.
But then again, who cares about regular users?!
What happens if you install the fileutils from rawhide?
fileutils does not change anything. However, I now understand that only
users served via NIS lose color vision. Root and all the local users see things
And one more stupid observation... Let me just summarize all:
Users served by NIS have lost colorful ls
It only happens under X
xterm, Konsole, rxvt - don't metter
Without X ls works better.
I mean "ls --color" works, of course. It's defaults what's somehow different
for local and network users.
*** Bug 57820 has been marked as a duplicate of this bug. ***
It not only "ls" that is missing its aliases for users served ny NIS. The
story is the same with "rm". "rm" removes silently without asking for
confirmation. I the case of "rm", however, aliases don't work in virtual
the reason is that /etc/profile.d/colorls.sh was only working for bash.
What's the current status?
NIS users were set up with a different shell?
That's right. NIS users in our heterogeneous environment had defaults
to /bin/tcsh, as it's more common in other unixes.
Here is what happenes for users with tcsh.
Scenario 1. Logging in in virtual console envokes /etc/csh.login and they see
Scenario 2. Firing up a terminal window under X misses /etc/csh.login and
envokes only /etc/csh.cshrc. No calls to /etc/profile.d/*.csh are made
resulting in non-color ls.
Using bash invokes /etc/bashrc in both cases and users see colors.
I'm changing it to fileutils. it's their problem.
fixed in 7.3