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 _______________________________________________ Bug-fileutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-fileutils
