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: Wed, 05 Oct 2005 21:40:34 -0400

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.
> 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.
> 
> 
> 
If that's so, why do I have to run eval "dircolors -b"
in the first place?

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.

If the default is in ls itself, why would you
need a 'dircolors' at all? It makes sense when you can have this
evaluate a file like .dir_colors. But, if the equivalent
of .dir_colors is compiled once and for all you can't
change it anyway, and you might as well go with the 
default stored into ls.

I had briefly thought that LS_COLORS could have been
made through earlier calls to dircolor,
from other terminal windows, but
that would violate their separateness. So, that's not
it.

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

Is this correct?

Nino







reply via email to

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