Red Hat Bugzilla – Bug 429121
Take advantage of 256 color terminals for color ls
Last modified: 2012-10-30 10:52:40 EDT
Description of problem:
Color ls does not take advantage of 256 color terminals, it only uses 16 colors
A lot of the colors used now are not very readable and plain do not look good.
For an example of how to properly take advantage of 256 color terminals try:
TERM=xterm emacs -nw SOME_FILE.c
and compare the colors used for syntax highlighting with the ones used by:
TERM=xterm-256color emacs -nw SOME_FILE.c
Version-Release number of selected component (if applicable):
Thanks for that new bugzilla ticket- just for clarification:
Would you prefer to have new separate /etc/DIR_COLORS.256colors only with TERMs
with 256 color support and those with 38;5;<color> style? Or to make it somehow
in current DIR_COLORS file? (this will require to create separate color section
for 8 colored and 256 colored TERMs)
(In reply to comment #1)
> Thanks for that new bugzilla ticket- just for clarification:
> Would you prefer to have new separate /etc/DIR_COLORS.256colors only with TERMs
> with 256 color support and those with 38;5;<color> style? Or to make it somehow
> in current DIR_COLORS file? (this will require to create separate color section
> for 8 colored and 256 colored TERMs)
IMHO it would be cleaner to have a new /etc/DIR_COLORS.256colors
AFAIK DIR_COLORS does no support conditionals, so separate color sections is not
so easy to implement.
xterm, gnome-terminal, konsole, rxvt and even putty all use the 38;5;<color> style.
What is needed is for someone that has some good artistic/color taste to look at
the 256 colors available and decide which one to use for each type of file.
Ideally the colors chosen would be very readable on both a white background
(which is the default for most terminals) and a black background (which some
Added DIR_COLORS file with 256 color support in coreutils-6.10-1.fc9 ... it is
just first attempt of colors, it is not yet reachable from colorls.csh nor
colorls.sh - anyway - those shell scripts needs to be rewritten (because of the
.xterm file is used even from gnome-terminal with black background) - I'm trying
to find suitable solution with usage of terminfo...
coreutils-6.10-5.fc9 RAWHIDE build adds support for 256 colors in colorls.sh/csh
scripts, so should solve your objections... please try it and let me know if it
is usable for F8 update.
(In reply to comment #4)
> coreutils-6.10-5.fc9 RAWHIDE build adds support for 256 colors in colorls.sh/csh
> scripts, so should solve your objections... please try it and let me know if it
> is usable for F8 update.
Thanks for doing this! I tried it.
May I suggest using some other color instead of cyan and bright green?
They are not easy to read on a white or light gray background.
34 instead of bright green (;10)
45 instead of cyan (;14)
No problem , thanks for suggestion... will do that in next RAWHIDE build (later
this week, I don't want to make separate build just for that) - at least that
;45 seems to be much better than ;14 on white/light gray background... if you
have other objections(functionality, other better colors), please let me know ...
After thinking a bit more about adding that as update to F8 - I decided to don't
make update with 256-colors DIR_COLORS file for stable F8. 256-colors DIR_COLORS
are built in RAWHIDE and will be shipped with F9. So closing that bugzilla as
Feel free to add any other suggestions about "better" color codes. They have to
be readable on all basic background colors(white,light gray and black).
I think it would be important that symlinks have a color different than other files (like .mp3 files, as of now). It's a lot confusing when browsing directories.
AFAIK the default Debian dircolor db isn't bad (uses teal for audio files, purple for images).