Bug 54309 - fileutils-4.x (was setup-2.5.7-1 or bash-2.05-9) shuts ls colors off
Summary: fileutils-4.x (was setup-2.5.7-1 or bash-2.05-9) shuts ls colors off
Alias: None
Product: Red Hat Raw Hide
Classification: Retired
Component: fileutils   
(Show other bugs)
Version: 1.0
Hardware: i386 Linux
Target Milestone: ---
Assignee: Bill Nottingham
QA Contact: David Lawrence
Depends On:
TreeView+ depends on / blocked
Reported: 2001-10-04 05:52 UTC by Alexei Podtelezhnikov
Modified: 2014-03-17 02:23 UTC (History)
1 user (show)

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

Attachments (Terms of Use)

Description Alexei Podtelezhnikov 2001-10-04 05:52:58 UTC
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 05:55:43 UTC
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 19:34:45 UTC
What happens if you install the fileutils from rawhide?

Comment 3 Alexei Podtelezhnikov 2001-10-04 20:14:38 UTC
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 20:26:23 UTC
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 18:04:11 UTC
*** Bug 57820 has been marked as a duplicate of this bug. ***

Comment 6 Alexei Podtelezhnikov 2002-01-15 22:17:14 UTC
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-18 02:25:17 UTC
the reason is that  /etc/profile.d/colorls.sh was only working for bash.
What's the current status?

Comment 8 Bill Nottingham 2002-01-25 04:38:05 UTC
NIS users were set up with a different shell?

Comment 9 Alexei Podtelezhnikov 2002-01-25 08:23:23 UTC
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 22:42:14 UTC
 fixed in 7.3

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