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 _______________________________________________ Bug-coreutils mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-coreutils
