bug-coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ls


From: Nino Pereira
Subject: Re: ls
Date: Thu, 06 Oct 2005 08:45:26 -0400

> 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 do the following: 

I copy the colorization information from dircolors into a file dirc by
$ dircolors -p > dirc
Then I edit dirc to convert statements like
.jpg 01;35 to touch temp.jpg
make dirc executable, and execute it. I get temporary files temp.ext
that should be colorized according to what's in dircolors.

I comment out the statement 'eval "dircolors -b" in the .bashrc file,
and go into a new terminal. 
ls -lotr --color=auto shows those temp files black, not colorized.

Then, I uncomment 'eval "dircolors -b" in .bashrc, go out and back
into the terminal, and lo: the files temp are colorized.

 My conclusion: ls's defaults differ from what's in dircolors.

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

> > 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`"

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

In fact, that this way of setting colors for ls didn't work
spurred me to ask the question that started this thread:
how do you do it?

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

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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]