Summary: | DIR_COLORS keyword RESET when /bin/dircolors is orphaned | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Stefan de Konink <stefan> |
Component: | [OLD] baselayout | Assignee: | Gentoo's Team for Core System packages <base-system> |
Status: | RESOLVED FIXED | ||
Severity: | minor | CC: | temporale |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
See Also: | https://bugs.gentoo.org/show_bug.cgi?id=509596 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
DIR_COLORS
output of install |
Description
Stefan de Konink
2008-06-04 00:40:40 UTC
works just fine for me: dircolors -b /etc/DIR_COLORS what version of coreutils ? make sure that `dircolors` is actually executing the version from coreutils and not any other binary what is the output of `locale` ? sys-apps/coreutils [R 6.12] LANG=nl_NL.UTF-8 LC_CTYPE="nl_NL.UTF-8" LC_NUMERIC="nl_NL.UTF-8" LC_TIME="nl_NL.UTF-8" LC_COLLATE="nl_NL.UTF-8" LC_MONETARY="nl_NL.UTF-8" LC_MESSAGES="nl_NL.UTF-8" LC_PAPER="nl_NL.UTF-8" LC_NAME="nl_NL.UTF-8" LC_ADDRESS="nl_NL.UTF-8" LC_TELEPHONE="nl_NL.UTF-8" LC_MEASUREMENT="nl_NL.UTF-8" LC_IDENTIFICATION="nl_NL.UTF-8" LC_ALL=nl_NL.UTF-8 nemesis skinkie # dircolors -b /etc/DIR_COLORS dircolors: '/etc/DIR_COLORS':71: niet-herkend sleutelwoord RESET It happens with many systems I have installed. post the full build log as an attachment as well as your /etc/DIR_COLORS file running the command in the specified locale works for me, and the source code seems to be sane Created attachment 155845 [details]
DIR_COLORS
Created attachment 155857 [details]
output of install
required documents added I had this issue too when I was calling dircolors from an older coreutils version and etc/DIR_COLORS was from a newer version. *** Bug 265843 has been marked as a duplicate of this bug. *** it's very simple ls -la /bin/dircolors ls -la /usr/bin/dircolors dircolors -b /etc/DIRCOLORS source /etc/profile dircolors -b /etc/DIRCOLORS ))) This is due to orphaned /bin/dircolors. root has ${PATH} = /sbin:/bin .... non-priv user has ${PATH} = .../usr/bin:/bin Therefore, when calling 'dircolors', which is done by /etc/bashrc upon non-login shells, the following happens: --as root-- #which dircolors #/bin/dircolors --as non-priv user-- $which dircolors $/usr/bin/dircolors Now here's the problem: $/bin/dircolors --version dircolors (GNU coreutils) 6.4 $/usr/bin/dircolors dircolors (GNU coreutils) 7.1 In other words: When root calls 'dircolors' it execs /bin/dircolors version 6.4 When normal user calls 'dircolors' it execs /usr/bin/dircolors version 7.1 equery b /bin/dircolors doesn't find anything, suggesting /bin/dircolors is orphaned. This coud be solved by deleting /bin/dircolors, or adding a test to /etc/bashrc, [ -x /usr/bin/dircolors ] && DIRCOLORS=/usr/bin/dircolors || DIRCOLORS=/bin/dircolors and then calling ${DIRCOLORS} instead of just 'dircolors'. the coreutils ebuild will now automatically delete /bin/dircolors if /usr/bin/dircolors exists and /bin/dircolors is GNU coreutils http://sources.gentoo.org/sys-apps/coreutils/coreutils-7.4.ebuild?r1=1.2&r2=1.3 |