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
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
