Re: ls

[Eric Blake]

> 
> > 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.
> > address@hidden:~$ 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