This service will be undergoing maintenance at 20:00 UTC, 2017-04-03. It is expected to last about 30 minutes
Bug 54309 - fileutils-4.x (was setup-2.5.7-1 or bash-2.05-9) shuts ls colors off
fileutils-4.x (was setup-2.5.7-1 or bash-2.05-9) shuts ls colors off
Product: Red Hat Raw Hide
Classification: Retired
Component: fileutils (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Bill Nottingham
David Lawrence
Depends On:
  Show dependency treegraph
Reported: 2001-10-04 01:52 EDT by Alexei Podtelezhnikov
Modified: 2014-03-16 22:23 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2002-01-25 03:24:28 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Alexei Podtelezhnikov 2001-10-04 01:52:58 EDT
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):

How reproducible:

Steps to Reproduce:
1. setup + bush update
2. colorful ls is no more

Additional info:
Comment 1 Alexei Podtelezhnikov 2001-10-04 01:55:43 EDT
Sorry, forgot to add. Root still has colors, that's regular users who lose them.
But then again, who cares about regular users?!
Comment 2 Bill Nottingham 2001-10-04 15:34:45 EDT
What happens if you install the fileutils from rawhide?
Comment 3 Alexei Podtelezhnikov 2001-10-04 16:14:38 EDT
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
Comment 4 Alexei Podtelezhnikov 2001-10-04 16:26:23 EDT
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.
Comment 5 Bernhard Rosenkraenzer 2002-01-10 13:04:11 EST
*** Bug 57820 has been marked as a duplicate of this bug. ***
Comment 6 Alexei Podtelezhnikov 2002-01-15 17:17:14 EST
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 
consoles either.
Comment 7 Alexei Podtelezhnikov 2002-01-17 21:25:17 EST
the reason is that  /etc/profile.d/ was only working for bash.
What's the current status?
Comment 8 Bill Nottingham 2002-01-24 23:38:05 EST
NIS users were set up with a different shell?
Comment 9 Alexei Podtelezhnikov 2002-01-25 03:23:23 EST
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 
ls colors.

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.
Comment 10 Alexei Podtelezhnikov 2002-05-18 18:42:14 EDT
 fixed in 7.3

Note You need to log in before you can comment on or make changes to this bug.