Bug 1196642 - DIR_COLORS.256color ls colors hard to read with white and dark gray background
Summary: DIR_COLORS.256color ls colors hard to read with white and dark gray background
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: coreutils
Version: 22
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Pádraig Brady
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-02-26 12:45 UTC by Lubomir Rintel
Modified: 2016-01-04 14:43 UTC (History)
9 users (show)

Fixed In Version: coreutils-8.21-22.fc20
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-04-23 16:06:35 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Lubomir Rintel 2015-02-26 12:45:08 UTC
Description of problem:

DIR_COLORS.256color uses dark variants of the colors for directories and links which are sometimes hard to read; DIR_COLORS variants look fine.

I've tested two terminals -- GNOME 3.14 gnome-terminal (TERM=xterm-256color, dark gray background) and xterm (TERM=xterm-256color, white background) and both look better with light variants:

The directories are dark blue in DIR_COLORS.256color variant. They're near to unreadable with GNOME terminal while the light variant is fine and looks better in white xterm too.

The symbolic links are dark cyan in DIR_COLORS.256color which is barely readable in white xterm. The light variant looks better in xterm as well as in GNOME.

Same apples to red (for *.rpm files?) -- light variant looks better on white xterm as well as on dark GNOME.

The light variants are used in grep and systemd tools and seems like they're a more interoperable choice for different backgrounds.

Please consider using more light variants by default for 256 color terminals.

Version-Release number of selected component (if applicable):

coreutils-8.22-19.fc21.x86_64

Thanks!
Lubo

Comment 1 Ondrej Vasik 2015-02-26 12:46:33 UTC
Agreed, colors should be adjusted to be better readable in default.

Comment 2 Lubomir Rintel 2015-04-17 16:35:37 UTC
Any chances of progress here?
Anythink I can do to help?

Comment 3 Pádraig Brady 2015-04-17 22:45:13 UTC
You can use this to display various colors databases side by side:

$ disp_colors() { sed "s/\([^=]*\)=\([^=]*\):/\x1b[\2m===\1===\x1b[0m\n/g"; }
$ paste <(dircolors /etc/DIR_COLORS.256color | disp_colors) <(dircolors /etc/DIR_COLORS | disp_colors) <(dircolors | disp_colors)

I find the current settings quite readable with the default and builtin gnome terminal color schemes, but agree there could be a few tweaks to improve.
Note when not using 256 colors then the palettes come into play and so need to be considered also.

I found hovering over the 256 color palette here useful:
http://www.pixelbeat.org/docs/terminal_colours/#256

The only changes I would make to DIR_COLORS.256color are to lighten dirs and executables a little with:

DIR 38;5;33
EXEC 38;5;40

The other rpm entries and only from the 8 color palette and so
no different from the standard DIR_COLORS file, and so determined
by the palette in effect.

BTW I find it strange that MULTIHARDLINK is not distinguished in DIR_COLORS,
while it is in DIR_COLORS.256. Personally I think it's quite specialised
to want to highlight files with more than one link (and would just highlight
the link count in that case anyway), so would also change to:

MULTIHARDLINK 00

Also while at it, we should sync with:
http://git.sv.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=v8.23-117-gb3ecf3b
http://git.sv.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=v8.22-20-g17d92a9
i.e. remove .axv .anx .axa; add .m4a .opus (both audio)

I'll do the above after giving the above comments a little time for consideration

Comment 4 Lubomir Rintel 2015-04-20 12:56:57 UTC
(In reply to Pádraig Brady from comment #3)
> The only changes I would make to DIR_COLORS.256color are to lighten dirs and
> executables a little with:
> 
> DIR 38;5;33
> EXEC 38;5;40

Definitely an improvement here.

I'd advocate for brighter colors, but I'm not going to take a risk of an almost literal bikeshed color reaction :) Also, my display is not calibrated so it might be that the fault is on my side.

Thank you.

Comment 5 Fedora Update System 2015-04-20 15:00:27 UTC
coreutils-8.23-9.fc22 has been submitted as an update for Fedora 22.
https://admin.fedoraproject.org/updates/coreutils-8.23-9.fc22

Comment 6 Ondrej Vasik 2015-04-21 07:09:48 UTC
Thanks Pádraig for taking this item, stuck with some RHEL stuff...

Comment 7 Fedora Update System 2015-04-21 18:45:26 UTC
Package coreutils-8.23-9.fc22:
* should fix your issue,
* was pushed to the Fedora 22 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing coreutils-8.23-9.fc22'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2015-6457/coreutils-8.23-9.fc22
then log in and leave karma (feedback).

Comment 8 Fedora Update System 2015-04-23 16:06:35 UTC
coreutils-8.23-9.fc22 has been pushed to the Fedora 22 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 9 Fedora Update System 2015-05-14 13:29:47 UTC
coreutils-8.22-22.fc21 has been submitted as an update for Fedora 21.
https://admin.fedoraproject.org/updates/coreutils-8.22-22.fc21

Comment 10 Fedora Update System 2015-05-14 18:51:52 UTC
coreutils-8.21-22.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/coreutils-8.21-22.fc20

Comment 11 Fedora Update System 2015-05-19 16:18:07 UTC
coreutils-8.22-22.fc21 has been pushed to the Fedora 21 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 12 Fedora Update System 2015-05-30 15:37:28 UTC
coreutils-8.21-22.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.


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