Quote:
|
That's not quite what I'm asking.
|
I understand K, but I think you're probably doing this the hard way. Additionally I have no idea how much green you need to add to the blue to make gray, I can't see it and in truth, I'm color blind, so I'm hardly the guy to ask about that.
Let me explain what I think is happening. $LS_COLOR (via the Dircolors db) has a color it's trying to paint default files. Since we've never made a "log" file a special file group, for $LS_COLOR it's just a default or normal file (therefor color). Don't assume "black" means a lack of color, it doesn't, $LS_COLOR picked "black" from a lot of different values.
xdefaults, which appears to be deprecated (check your distro) is trying to paint it another color. It would be easier to do this if they'd stop arguing, wouldn't it?
Now you can disable .xdefaults attempts to paint the terminal, just remove the appropriate lines in the ~/.xdefaults directory, but you're not going to be able to stop $LS_COLOR from doing it's job, even if you empty the values in the hash table, there's a default color stored in the system, it'll just go with what it knows.
If you look at info coreutils 'dircolor' it will tell you that the $LS_COLOR local hash table (your ~/.dircolors file) is only going to be read it you put a little script that evaluates it in your ~/.bashrc directory. So do that.
The next step is to disable .xdefaults attempts to re-write what $LS_COLOR has already written and you should have total, fine grain control over every file type that interests you via the $LS_COLOR variable at the database level which will give you a stable, fully functional fix as long as $LS_COLOR remains in your disto.
