Description of problem: The colours used by ls don't follow those defined in the Terminal palette settings. As a result, they sometimes have legibility issues due to low contrast. They are also inconsistent with the colors used throughout the desktop. This, as I understand it, is because ls is using the 256 color palette, rather than the terminal-provided 16 color palette. The gnome-terminal developers have actually been working on improving the legibility of the 16 color palette, but these improvements are being ignored by ls. If you rm /etc/DIR_COLORS.256color, the 16 color palette is used instead of the 256 color palette. Version-Release number of selected component (if applicable): 8.31-9.fc31 (not really relevant though) How reproducible: Every time Steps to Reproduce: Run ls in a location that will give you a variety of colors (say, /usr/libexec). Actual results: The colors don't follow those configured in the terminal. Expected results: The colours match those configured in the terminal.
You do not need to change anything in /etc . This can be tweaked per user (via dot files in $HOME) or per session (via environment variables). Moreover it is enabled only if the terminal claims to support 256color sequences. See the logic in coreutils-colorls.sh: https://src.fedoraproject.org/rpms/coreutils/blob/2f7b3e0a/f/coreutils-colorls.sh The 256color support was introduced upon a user request 12 years ago: bug #429121 I do not use it myself and must admit that I do not remember any Fedora users asking about it anytime recently. So it either works well enough, or it is not widely used any more.
I think 256 color is used by default. I changed Fedora to use 256 color terminals by default years ago: https://fedoraproject.org/wiki/Features/256_Color_Terminals I see that central config mechanism was changed a while back: https://fedoraproject.org/wiki/Changes/Drop_256term.sh Now it seems left to each terminal to set TERM. I think since gnome-terminal 3.16 (vte 0.40) it sets TERM=xterm-256color by default, and I've confirmed my TERM=xterm-256color with gnome-terminal-3.36.1.1-1.fc32.x86_64
To be clear, I was speaking about the 256color support in coreutils and the palette specified in /etc/DIR_COLORS.256color . It is a file maintained downstream-only in Fedora. As far as I know, there is no equivalent file upstream. I do not know whether other Linux distros use something similar. But if they do, we are not synchronizing the palette with them in any way.
The concrete request here is to stop that. Don't ship /etc/DIR_COLORS.256color as a downstream, Fedora-only thing.
No objections from me. Dropping it means one less thing to maintain. On the other hand, Red Hat Bugzilla is not the right place to discuss this. Please take the discussion to the appropriate channels. Once I see there is an agreement on this I will be happy to implement the proposed change.
Why not fix GNOME Terminal to handle 256 colors? Konsole *finally* did this a little while back...
(In reply to Kamil Dudka from comment #3) > To be clear, I was speaking about the 256color support in coreutils and the > palette specified in /etc/DIR_COLORS.256color . It is a file maintained > downstream-only in Fedora. As far as I know, there is no equivalent file > upstream. I do not know whether other Linux distros use something similar. > But if they do, we are not synchronizing the palette with them in any way. What do you think is the right place to discuss a change to the Fedora coreutils package, if not the coreutils bugzilla ?
(In reply to Kamil Dudka from comment #5) > No objections from me. Dropping it means one less thing to maintain. On > the other hand, Red Hat Bugzilla is not the right place to discuss this. > Please take the discussion to the appropriate channels. Once I see there is > an agreement on this I will be happy to implement the proposed change. Even if gnome-terminal let you select 256 color palettes, we still want ls to use the palette that the terminal provides, not one that it found somewhere on the filesystem.
(In reply to Matthias Clasen from comment #7) > What do you think is the right place to discuss a change to the Fedora > coreutils package, if not the coreutils bugzilla ? You can see that not many people joined the discussion when this feature was initially proposed in bug #429121. The coreutils bugzilla is a reliable channel to reach downstream maintainers of coreutils, but not so much to reach maintainers of affected packages, or even end users. Allan has raised the topic on fedora-devel mailing list, which I believe will help us to get some feedback.
> Why not fix GNOME Terminal to handle 256 colors? > Konsole *finally* did this a little while back... I don't know what you exactly mean by "handle 256 colors". We are talking about terminals, so everything has 4 heads and 3 tails. :) VTE, which is the terminal emulator used by GNOME Terminal and all GTK-based terminal applications, has supported 256 colour palettes for more than half a decade at least. Since December 2014, it has been setting the TERM environment variable to "xterm-256color" by default: https://gitlab.gnome.org/GNOME/vte/-/commit/82a8b0697dd948fa488b5a51ee7391deb35d49be However, supporting 256 colours doesn't mean that it's easy to tweak all of them. Most (all?) terminal colour palettes in the wild only specify a 16 colour palette, and most (all?) terminal emulators set the remaining 240 colours to the exact same values. This means that, in practice, we can only change the 16 colour palette. So, if 'ls' is using the 256 colour palette, then we have no way to tweak the remaining 240 colours in the palette. Hence for the sake of sanity, we want 'ls' to only use the 16 colour palette on Fedora Workstation, because it's something that we can actually tweak and configure.
So far, no objections on the fedara-devel thread: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/SKO7BKFOB2WTIHFQT73A6QSGOCO4R6TZ/
dist-git commit: https://src.fedoraproject.org/rpms/coreutils/c/441f1d75
Thanks, Kamil!
Yes, thank you!
No problem. Thank you for helping me to make the package easier to maintain ;-)
The fix for this bug caused unexpected user experience degradation: bug #1884264 I have proposed a Fedora 33 Release Note which suggests a solution: https://pagure.io/fedora-docs/release-notes/issue/557
Thanks for doing that, Kamil!