Bug 496402 - Wrong ls colors in our default configuration
Wrong ls colors in our default configuration
Status: CLOSED CANTFIX
Product: Fedora
Classification: Fedora
Component: coreutils (Show other bugs)
13
All Linux
low Severity medium
: ---
: ---
Assigned To: Ondrej Vasik
Fedora Extras Quality Assurance
:
: 570511 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-04-18 13:52 EDT by Owen Taylor
Modified: 2011-06-06 08:02 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-06-06 08:02:02 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Owen Taylor 2009-04-18 13:52:57 EDT
So, there was the recent change:

===
* Thu Mar 19 2009 Ondrej Vasik <ovasik@redhat.com> 7.1-7
- do not ship /etc/DIR_COLORS.xterm - as many terminals
  use TERM xterm and black background as default - making
  ls color output unreadable
- shipping /etc/DIR_COLORS.lightbgcolor instead of it for
  light(white/gray) backgrounds
===

Now, I can't argue with the logic of that - TERM=xterm doesn't mean that the background is either light or dark.

*However*, as we ship Fedora we default to using white background colors in gnome-terminal and xterm. (I don't know about konsole offhand)

So it me, that if we believe that DIR_COLORS.lightbgcolor is the right set of colors with a light background, then we should make sure that people get those colors out of the box. We shouldn't ask users to:

 ln -s /etc/DIR_COLORS.lightbgcolor ~/.dircolors.xterm

to fix things to work right. (is that the preferred way to do it?)

How should this be addressed?
Comment 1 Ondrej Vasik 2009-04-20 10:39:02 EDT
I'm ok to add some autocheck to colorls.{sh,csh} once it will be possible to detect the background color (or at least color type) by some tput command or by some sequence sent to terminal.

At the moment there is no such thing (discussed with xterm maintainer, maybe could be added in future), so the symlink is probably best and easiest way. Actually - upstream coreutils are shipping just one type of dircolors/LS_COLORS - that one which is now used as default. Those color types are chosen to be acceptably readable on white/gray/black background, but on light background is the DIR_COLORS.lightbgcolor set a bit better. On other hand - non-bold colored directory color (from lightbgcolor set) is very hard to read on dark/black background.
Comment 2 Bug Zapper 2009-06-09 10:04:50 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle.
Changing version to '11'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 3 Ondrej Vasik 2010-03-10 03:37:00 EST
*** Bug 570511 has been marked as a duplicate of this bug. ***
Comment 4 Ondrej Vasik 2010-03-10 03:37:13 EST
Kamil said on Gentoo a bit different color is used for "classic blue" color - maybe that's the way - to choose a bit lighter color for common "dark" blue on system level - as we have only 16 colors (if counting black and white) for general terminals.
Maybe something like 01;38;5;39 color (try echo -e "\033[01;38;5;39mcolor\033[000m\033[1;34mcolor\033[000m" to see the difference) - this is visible on both dark and light background... but requires 256 color suppport.
Comment 5 Bug Zapper 2010-03-15 08:32:21 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 13 development cycle.
Changing version to '13'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 6 Bug Zapper 2011-06-02 14:08:41 EDT
This message is a reminder that Fedora 13 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 13.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '13'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 13's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 13 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 7 Ondrej Vasik 2011-06-06 08:02:02 EDT
I'm going to CANTFIX this manually ... no way to go, no way to get better colors on every terminal... This 256 color scheme is better on both backgrounds, but still not perfect and not suitable for all terminals. With no chance of guessing dark/light background of the terminal, it can't be fixed in coreutils.

Note You need to log in before you can comment on or make changes to this bug.