Re: ls

[Eric Blake]

> On Thu, 2005-10-06 at 00:54 +0200, Alfred M. Szmidt wrote:
> >    I had expected that omitting this command would make coloration
> >    disappear, but this is not the case. Why is that?
> > ...
> >    alias ls='ls --color=auto'
> >                 ^^^^^^^^^^^^
> > 
> > Thats why, ls has defaults for colors.
> 
> Through all these exercises I had
> understood that 'dircolors' has the color information
> data compiled directly in 'dircolors'. When you evaluate
> dircolors you put the color information out to the system,
> in the environment variable LS_COLORS. So, if you were to omit the
> call to dircolors, the system should not know any
> color information. That's what I was testing.

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).  'dircolors -b' and
'dircolors -c' with no filename use the default builtin database (and
not a set filename) to populate LS_COLORS.

The upshot of this all is that it only makes sense to use dircolors
if you intend to alter the database to your own needs, by using
dircolors ability to parse a file rather than using its builtin database.
Currently, the syntax of the file that dircolors expects can be
found by running 'dircolors -p', but we would like to move it into
the info pages (help is appreciated).

> My conclusion: for debian (and other systems that
> don't have a .dir_color-equivalent file) you don't
> need dircolors. 

No, you can make your own .dir_color, or any other name,
and then tell dircolors to use that, as in

eval "`dircolors -b ~/.my-dir-colors`"

For that matter, you are correct that different terminals
can have different color schemes, by using different files
as input to dircolors to create different LS_COLORS values.

--
Eric Blake