> > > There are two builtin databases, which should have identical > > information (although if they don't, you should report it as a bug). > > 'dircolors -p' will output the builtin dircolors database, and ls > > --color=auto > > when LS_COLORS is undefined will use the builtin ls database (there > > is no way to print the default ls database). > > In that case I do want to report a bug: AFAIK the data base inside ls > differs from that in .dircolors.
I guess I was wrong. The ls defaults only cover file type categories, for example, executables color with 01;32, but does not do any file extension parsing. The dircolors defaults should match the file type categories (for example, dircolors -p | grep EXEC shows that the EXEC keyword, which controls the executable category, is 01;32). It is only a bug if the two databases disagree on the default color of a file type category. But the dircolors database also includes file extensions; for example, .gz maps to 01;31. So if you have a .gz file that is also executable, the ls defaults will be green, but the dircolors defaults will be red. So, there IS a reason to use dircolors, even without specifying any file to parse, because dircolors adds file name extension coloring that ls will only do if LS_COLORS is set. > > > I'd be happy to help you fix the info and man pages. Just let me know > how to do that. I'll have to add the debian-specific quirks, then. If you really want to do a man page, it should be dircolors.5 to describe the file format. Currently, coreutils only creates man1 pages, using help2man, so there is no precedent as to how to create a man5 page from existing documentation. I would recommend starting with the info page - check out CVS, then edit doc/coreutils.texi (I've started some edits on my own, but unfortunately have not done anything with them for months, including making those edits public, because my employer still hasn't allowed me to assign copyright to FSF). Then it is just a matter of adding a new info page that describes the grammar that dircolors parses (you will have to reverse engineer that information from reading the dircolors.c source). > Sorry, this does not work under debian, and, presumably, > neither at any 'Slackware-type system' as a rather > terse formulation in the man pages mentions. > > [EMAIL PROTECTED]:~$ eval "'dircolors -b ~/.dir_colors'" > bash: dircolors -b ~/.dir_colors: No such file or directory Well, it will only work if you actually create such a file :) I would recommend doing dircolors -p > ~/.dir_colors Then use your favorite editor to improve it to your liking. Just because the distro doesn't create such a file for you when you create a new user doesn't mean that you can't do it at a later time! > > I found one way that works, namely, change LS_COLORS directly > in .bashrc, with a statement like > > # since the --color option in ls takes its information from the > # environment variable LS_COLORS, an alternative is to add what > # you want directly to this environment, like so: > LS_COLORS='*.eps=01;31':$LS_COLORS > LS_COLORS='*.tex=01;31':$LS_COLORS I would not recommend this. The format of LS_COLORS is undocumented, and subject to change. dircolors exists to make changing the syntax of LS_COLORS transparent - no matter if ls and dircolors are changed simultaneously to agree on a new syntax for LS_COLORS, dircolors will still parse the same input files. -- Eric Blake _______________________________________________ Bug-coreutils mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-coreutils
