Bug 430823

Summary:	should discard errors from dircolors
Product:	Red Hat Enterprise Linux 4	Reporter:	Mikel Ward <mikel>
Component:	coreutils	Assignee:	Ondrej Vasik <ovasik>
Status:	CLOSED ERRATA	QA Contact:	BaseOS QE <qe-baseos-auto>
Severity:	low	Docs Contact:
Priority:	low
Version:	4.6	CC:	rainwoodman, rvokal, twaugh
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
URL:	http://thread.gmane.org/gmane.comp.gnu.coreutils.bugs/12481
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2009-05-18 20:07:36 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	450508, 458804

Description Mikel Ward 2008-01-29 23:13:28 UTC

/etc/profile.d/colorls.sh tries to run eval `dircolors --sh "$COLORS"`.  This
can generate errors if the configuration file (e.g. ~/.dircolors) is designed
for a newer version of ls.

For instance, dircolors recently introduced SETUID, SETGID,
STICKY_OTHER_WRITABLE, OTHER_WRITABLE, and STICKY options.  I want to set a
color for them in my ~/.dircolors, but I also want to share my ~/.dircolors on
older Red Hat and Fedora systems.

If I do so, I get these errors when logging in to a RHEL 4system

dircolors: `/home/mward/.dircolors':37: unrecognized keyword STICKY_OTHER_WRITABLE
dircolors: `/home/mward/.dircolors':38: unrecognized keyword OTHER_WRITABLE
dircolors: `/home/mward/.dircolors':39: unrecognized keyword STICKY

I doubt you're going to fix this in RHEL 4, but at least going forwards, please
add 2>/dev/null to that line in colorls.sh to avoid such warnings.

(I also notice that you're sourcing ~/.dir_colors after ~/.dircolors.$TERM,
which seems wrong.)

Comment 1 Mikel Ward 2008-01-29 23:15:52 UTC

See the URL for the brief discussion on the coreutils mailing list.

Comment 2 Ondrej Vasik 2008-01-30 11:24:30 UTC

Thanks for report... I'm on that mailing list so I already read this item there
;). I think is more probable to have it fixed in RHEL4 than in FC-5 - as FC-5 is
EOL. So I will change the product to RHEL-4 and it will get fixed in next
maintainance release of RHEL-4 coreutils (as I agree that the error output
should be redirected to dev/null). 
Anyway - colorls.sh and colorls.csh have to be rewritten, because they use
DIR_COLORS.xterm even on the gnome-terminal with dark background and because of
256 color support, so I will fix your objections there too.

Comment 3 Ondrej Vasik 2008-01-31 16:59:53 UTC

Fixed and built as coreutils-6.10-4.fc9 in RAWHIDE branch of Fedora.

Comment 4 RHEL Program Management 2008-09-17 13:53:51 UTC

This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.

Comment 6 Feng Yu 2008-09-28 19:16:35 UTC

coreutils-6.10-30.fc9.i386 also suffer from the same bug:

dircolors: `/etc/DIR_COLORS.xterm':68: unrecognized keyword CAPABILITY

Comment 7 Ondrej Vasik 2008-09-29 07:50:39 UTC

(In reply to comment #6)
> coreutils-6.10-30.fc9.i386 also suffer from the same bug:
> dircolors: `/etc/DIR_COLORS.xterm':68: unrecognized keyword CAPABILITY

Thanks for comment, however, that's different issue. Actually capability support was added to F-9 (and this bugzilla is about different RHEL-4 issue) with 6.10-28.fc9 and fully removed by 6.10-30.fc9 due to tcsh bug. This removal accidently caused error messages (bz #457342 and others) and capability option(and libcap2 dependency) was removed from ls and dircolors for F-9. In fact the best way would be to readd the code for CAPABILITY handling to ls and dircolors - but this would bring additional libcap2 dependency without any usage. But probably it has to be done...

Comment 12 errata-xmlrpc 2009-05-18 20:07:36 UTC

An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2009-0959.html