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
Version-Release number of selected component (if applicable):
Steps to Reproduce:
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
$ /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
> $ /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:
Oh, maybe the spec file should generate DIR_COLORS at build time -- is that what
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
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
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?