Bug 429121

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
people use).

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.

For example:
34 instead of bright green (;10)
and
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
NEXT_RELEASE. 

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).