Rodolfo Perez wrote: > On Sat, 2010-05-22 at 14:57 -0500, Bruce Dubbs wrote: >> That doesn't make sense. Both dircolors and ls are from coreutils. If >> you use the same version of coreutils to generate /etc/dircolors, then >> ls should understand it. >> >> On a recent LFS system, /etc/dircolors does not have an hl prefix. Even >> checking back to an old copy of dircolors (binary and data file) >> generated Nov 2005, there is no hl prefix. >> >> -- Bruce > > Hmmmmmm ... but I do get the message: > > root [ /etc ]# ls >>> ls: unrecognized prefix: hl >>> ls: unparsable value for LS_COLORS environment variable > > with lfs 6.4 (coreutils-6.12). > > Bruce can you explain this? Is lfs 6.4 "too old"? > Could it be an error, coming from wrong file right settings?
No, 6.4 is not too old. I do seem to recall an issue with hard links. See the discussion starting at http://www.mail-archive.com/[email protected]/msg16736.html On an LFS 6.5 system, my $LS_COLORS has hl=44;37 and it is recognized fine by ls. It is generated by the entry in /etc/dircolors of HARDLINK 44;37 # regular file with more than one link When I port back a newer file to an older system, I get: $ eval $(dircolors -b dircolors) dircolors: `dircolors':64: unrecognized keyword RESET dircolors: `dircolors':68: unrecognized keyword HARDLINK dircolors: `dircolors':77: unrecognized keyword CAPABILITY My conclusion is that you have a mismatch between your dircolors executable, ls, and the /etc/dircolors (or ~/.dircolors) files. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
