ls color listing bug

[Bryon Daly]

Hello,

I'd like to report what I think is a bug (or at least a flaw) in the way
"ls" handles coloring the files it lists (when using --color=auto or 
--color=always).

This is ls version 4.1, which I just downloaded and built this week for
Solaris 7 (SunOS 5.7 sun4u sparc SUNW,Ultra-60)

The problem behavior is that when coloring is enabled, it ALWAYS colors
executable files using the using the selected executable color (or the 
default bold green if LS_COLORS does not set something different).  The 
problem with this is that this color ALWAYS overrides any other color 
associated with the file extension.

In at least two cases I can think of, this is not desirable:
1) It'd be nice to be able to categorize different types of 
executables with different colors, based on their given extension.  
(ie: one color for scripts (which you could assign extensions to, 
with mappings in the dircolors table), and another color for binary 
files (which you wouldn't give an extension to and would use the 
standard color for executable files, defined as EXEC in the 
dircolors table).  As it works right now, this can't be done 
because the generic executable color attribute overrides the 
file extension color attribute.

So for example, if you set up dircolors with a file containing:
EXEC 01;32
.ksh 01;33

Any executable *.ksh scripts would still be colored green (the EXEC 
color) instead of yellow (the color specified for *.ksh).  (From 
experimentation, I've found the order of the color assigments doesn't 
matter).


2) More consistency... In my work environment, we have a number  of 
source and other files which inexplicably are marked excutable.  
(They're under revision control and it's unfeasible to change them 
across all their assorted branches).  I'd like to set a standard 
color for source files, but some files in some directories end up 
with the executable color instead of the *.c color, for instance.  
I've tried setting the EXEC color to NORMAL, but this *STILL* 
overrides the extension-based color.
I.E.: if you evaluate a dircolors file with the following:

EXEC 00
.c 01,37

This results in non-executable *.c files showing in bold white, while
executable *.c files show as in the normal text color.  Also, if an 
EXEC color is not specified, it always uses the default bold green and 
still overrides the extension-based color.

I hope this all makes sense.  I can explain further/provide more info 
if needed.

One fix would be to change the precedence that color attributes are 
applied in so that file extensions have priority over the executable 
attribute.  

My preferred fix for this problem would be the ability to specify the 
precedence that color attributes should be applied in.  

While I'm writing this, I'd also like to put in a feature request: 
Make ls look at an environment variable that if present determines 
if it should use color (ie: LS_USE_COLOR=never/true/always), so that the
--color command isn't necessary to specify all the time.

Thanks,
Bryon Daly