| 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 |
||
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 |
It annoys me very much lately to see a message after switching to root using su, about: dircolors: '/etc/DIR_COLORS':71: unrecognized keyword RESET output: skinkie@nemesis ~ $ su - Wachtwoord: nemesis ~ # logout skinkie@nemesis ~ $ su Wachtwoord: dircolors: '/etc/DIR_COLORS':71: niet-herkend sleutelwoord RESET Reproducible: Always Steps to Reproduce: paludis 0.26.1 Paludis build information: Compiler: CXX: i686-pc-linux-gnu-g++ 4.2.3 (Gentoo 4.2.3 p1.0) CXXFLAGS: -O2 -march=pentium4 -pipe -fomit-frame-pointer LDFLAGS: DATE: 2008-05-19T03:43:55+0200 Libraries: C++ Library: GNU libstdc++ 20080201 Reduced Privs: reduced_uid: 103 reduced_uid->name: paludisbuild reduced_uid->dir: /var/tmp/paludis reduced_gid: 1001 reduced_gid->name: paludisbuild Paths: DATADIR: /usr/share LIBDIR: /usr/lib LIBEXECDIR: /usr/libexec SYSCONFDIR: /etc PYTHONINSTALLDIR: RUBYINSTALLDIR: Repository virtuals: format: virtuals Repository installed-virtuals: format: installed_virtuals root: / Repository gentoo: format: ebuild location: /usr/portage append_repository_name_to_write_cache: true binary_destination: false binary_keywords: binary_uri_prefix: builddir: /var/tmp/paludis cache: /usr/portage/metadata/cache distdir: /usr/portage/distfiles eapi_when_unknown: 0 eapi_when_unspecified: 0 eclassdirs: /usr/portage/eclass ignore_deprecated_profiles: false layout: traditional names_cache: /usr/portage/.cache/names newsdir: /usr/portage/metadata/news profile_eapi: 0 profiles: /usr/portage/profiles/default-linux/x86/2007.0 securitydir: /usr/portage/metadata/glsa setsdir: /usr/portage/sets sync: rsync://rsync.nl.gentoo.org/gentoo-portage sync_options: use_manifest: use write_cache: /var/empty Package information: paludis@1212540010: [QA version_spec.too_long] In program paludis --info: ... When fetching versions of 'sys-apps/baselayout' in installed: ... When loading package names from '/var/db/pkg' in category 'sys-apps': ... When parsing package dep spec '=sys-apps/net-tools-1.60_p20071202044231-r1 ': ... When parsing version spec '1.60_p20071202044231-r1': ... Number part '20071202044231' exceeds 8 digit limit permitted by the Packag e Manager Specification (Paludis supports arbitrary lengths, but other package m anagers do not) app-admin/eselect-compiler: (none) app-shells/bash: 3.2_p39 dev-java/java-config: 1.3.7 2.1.6 dev-lang/python: 2.4.3-r4 2.5.2-r4 dev-python/pycrypto: 2.0.1-r6 dev-util/ccache: (none) dev-util/confcache: (none) sys-apps/baselayout: 2.0.0 sys-apps/openrc: 0.2.4-r1 sys-apps/sandbox: 1.2.18.1-r2 sys-devel/autoconf: 2.13 2.62 sys-devel/automake: 1.10.1-r1 1.5 1.7.9-r1 1.9.6-r2 sys-devel/binutils: 2.18-r1 sys-devel/gcc-config: 1.4.0-r4 sys-devel/libtool: 1.5.26 virtual/os-headers: 2.6.25-r3 (for sys-kernel/linux-headers::installe