Re: ls

[Nino Pereira]

Eric,

I'm a little late in responding because I'm not sophisticated
enough to digest all the information you offer immediately.
And even now I don't know exactly how to follow your suggestion
to help edit the docs for dircolors to describe the differences
in color handling between ls and dircolors (in debian). 

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

I didn't see the file with the docs, doc/coreutils.texi, on
my system in the place where my docs live, /usr/share/doc/coreutils.
This does have name of dircolors's author, H. Peter Anvin, but that's
as far as it goes.

Also, the problem is, I think, not so much in dircolors as well in
the fact that debian's version of dircolors doesn't seem to read
the file .dir_colors.  
> > 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!

In my earlierst attempt to set the colors I did make such a file,
or at least I checked that I had such a file. Then I edited this
file, and tried it. Didn't work. Only then did 
> 
> > 
> > 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
> 
You say: 
> 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.

and this is undoubtedly true. Still, it works. It will work even if
the format of LS_COLORS changes, provided that you pick the correct
format up by looking it up in LS_COLORS itself (by e.g., $LS_COLORS).

Still, if you can tell me more precisely where I can find the
.tex form of the doc file (or, even easier but less instructional for
me, email it) I'll be happy, and in fact delighted,
to offer some text that describes what I
did to make things work in debian.

Please note that I don't mind deconstructing a c program,
but my long-since-deprecated expertise in programming is
in fortran, not c.

Nino


> --
> Eric Blake
> 
> 
>