Bug 430823 - should discard errors from dircolors
should discard errors from dircolors
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: coreutils (Show other bugs)
All Linux
low Severity low
: ---
: ---
Assigned To: Ondrej Vasik
Depends On:
Blocks: 450508 458804
  Show dependency treegraph
Reported: 2008-01-29 18:13 EST by Mikel Ward
Modified: 2009-05-18 16:07 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-05-18 16:07:36 EDT
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 Mikel Ward 2008-01-29 18:13:28 EST
/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,
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 18:15:52 EST
See the URL for the brief discussion on the coreutils mailing list.
Comment 2 Ondrej Vasik 2008-01-30 06:24:30 EST
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 11:59:53 EST
Fixed and built as coreutils-6.10-4.fc9 in RAWHIDE branch of Fedora.
Comment 4 RHEL Product and Program Management 2008-09-17 09:53:51 EDT
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
Comment 6 Feng Yu 2008-09-28 15:16:35 EDT
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 03:50:39 EDT
(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 16:07:36 EDT
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.


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