Description of problem: Color ls does not take advantage of 256 color terminals, it only uses 16 colors now. 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): coreutils-6.9-12.fc8
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).