Description of problem: I have set the resource "XTerm.termName: xterm-256color". Now `ls` output in xterm is always in black and white, no colors at all. However if I start another xterm with "xterm -tn xterm" (i.e. use the default 8-color term), `ls' output has colors. Version-Release number of selected component (if applicable): xterm-225-2.fc7 How reproducible: 100% Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
dircolors don't know about xterm-256color, an extra entry in /etc/DIR_COLORS* would be needed to have this working. Also would be nice to have an entry for rxvt-unicode terminal.
Thanks for the report. This was fixed in coreutils-6.0. rawhide is at coreutils-6.9. $ /usr/bin/dircolors --p|grep -E uni\|256 TERM rxvt-unicode TERM xterm-256color $ /usr/bin/dircolors --ver|head -1 dircolors (GNU coreutils) 6.9
(In reply to comment #2) > Thanks for the report. This was fixed in coreutils-6.0. rawhide is at coreutils-6.9. > > $ /usr/bin/dircolors --p|grep -E uni\|256 > TERM rxvt-unicode > TERM xterm-256color > $ /usr/bin/dircolors --ver|head -1 > dircolors (GNU coreutils) 6.9 Does that mean you can't reproduce this bug?
/etc/profile.d/colorls.* don't use the precompiled database, so /etc/DIR_COLORS needs to be updated.
Ah. I see what you mean. If there is a good reason to maintain /etc/DIR_COLORS separately from the database that is printed by dircolors -p, then it would be nice to generate it, so that they stay in sync. Tim, if you're interested, I'm sure we can merge things so that it can be generated -- or even identical to the built-in DB. Ideally, /etc/profile.d/* would use something like this: eval "`dircolors`" by default.
Oh, maybe the spec file should generate DIR_COLORS at build time -- is that what you mean?
That's a good first step. In addition, if the shell snippets in /etc/profile.d/* were to use eval "`dircolors --whatever`" (and not use /etc/DIR_COLORS anymore), then they would work also with older and newer versions of ls/dircolors, rather than just with the system-installed versions.
To work around the bug before a fixed coreutils is available: dircolors -p > ~/.dir_colors
Please also support "screen-256color" along with term-256color and rxvt-unicode.
(In reply to comment #9) > Please also support "screen-256color" along with term-256color and rxvt-unicode. ^ read 'xterm-256color'
It would be nice if dircolors used terminfo or termcap rather than a set of hardcoded values which are a nuisance to everyone else.
Has this bug been forgotten? I would love to see it fixed in Fedora 9.
Yes and no. As you can see in changelog(rawhide, 6.9-12.fc9) I ported upstream supported dircolors to dircolors.hin file - but this was not enough because shipped DIR_COLORS and DIR_COLORS.xterm are not generated automatically and have to be modified manually. Unfortunately - I forgot to do that in that build. Now added and built as coreutils-6.9-17.fc9. Closing RAWHIDE, feel free to reopen it if adding requested TERMs to DIR_COLORS and DIR_COLORS.xterm is not sufficient for you. Anyway - even this bugzilla got closed I will think about generating those DIR_COLORS files at build time - maybe at least DIR_COLORS file could be generated from dircolors.hin which provides (hopefully) complete list of colored TERMs supported by ls.
Thank you for working on fixing this. Is it possible to push the update for F8?