[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
ls color listing bug
From: |
Bryon Daly |
Subject: |
ls color listing bug |
Date: |
Thu, 12 Jul 2001 18:15:37 -0400 |
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
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- ls color listing bug,
Bryon Daly <=