alacritty: alacritty terminfo is not compatible with GNU dircolors

Which operating system does the issue occur on?

Arch Linux - 5.0.3

If on linux, are you using X11 or Wayland?

X11 with KDE Plasma. This problem does not seem to happen on Wayland with Sway.

Summary - The environment variable LS_COLORS is defined, but set to empty string. This causes issues with nearly all programs relying on this for color output. Unsetting this variable seems to fix most problems.

$ env | grep COLOR

COLORTERM=truecolor
LSCOLORS=Gxfxcxdxbxegedabagacad
LS_COLORS=

Expected Behavior - LS_COLORS is set depending on the colors defined in the alacritty config file.

Strange Notes This behavior seems to be unique to my KDE Plasma setup. The same computer with Sway on Wayland produces the correct LS_COLORS behavior. However, my setup with KDE Plasma is repeatable across multiple machines.

About this issue

Original URL
State: closed
Created 5 years ago
Reactions: 4
Comments: 17 (11 by maintainers)

Commits related to this issue

zsh: dircolors fix GNU dircolors doesn't recognize alacritty, see https://github.com/alacritty/alacritty/issues/2210 — committed to kaworu/dotfiles by kaworu 3 years ago
Update INSTALL.md with instructions for ls color Based on information I found at https://www.reddit.com/r/Gentoo/comments/kd588m/alacritty_show_ls_without_colors/ and https://github.com/alacritty/ala... — committed to volkertb/alacritty by volkertb 3 years ago

Most upvoted comments

Rename the alacritty TERM to an accepted term match, such as xterm-alacritty or color-alacritty. This should solve the issue.

Alacritty is not a version of xterm. Advertising it as such is incorrect and will just lead to packages like vim requiring to add more and more complex hacks.

Submit a pull request to upstream GNU requesting they adopt our TERM file name, alacritty. I strongly suspect this to be met with significant pushback. Likely this will be fighting an uphill battle.

GNU dircolors is at fault here, so that’s where the issue needs to be fixed. I would not expect a lot of pushback, other applications have been very cooperative in resolving similar issues.

Since this is not an Alacritty issue, this is the wrong place to resolve and discuss it.

Note that setting LS_COLORS yourself works perfectly fine and I haven’t run into any issues with that. So if the dircolors command does not support terminal emulators that don’t fit into their custom terminfo table, circumventing it by just taking the result from xterm and reusing it in Alacritty should be trivial (something like export LS_COLORS='ow=36:di=34:fi=32:ex=31:ln=35:' is all it takes).

chrisduerr on Mar 25, 2019

The issue is not with oh-my-zsh as I thought, but with GNU dircolors (part of the coreutils).

However, it is as simple as I thought. Here are my thoughts:

Solution 1

Rename the alacritty TERM to an accepted term match, such as xterm-alacritty or color-alacritty. This should solve the issue.

Explanation GNU dircolors matches a TERM against the following directories, taken from the manpage:

TERM Eterm
TERM ansi
TERM *color*
TERM con[0-9]*x[0-9]*
TERM cons25
TERM console
TERM cygwin
TERM dtterm
TERM gnome
TERM hurd
TERM jfbterm
TERM konsole
TERM kterm
TERM linux
TERM linux-c
TERM mlterm
TERM putty
TERM rxvt*
TERM screen*
TERM st
TERM terminator
TERM tmux*
TERM vt100
TERM xterm*

Solution 2

Submit a pull request to upstream GNU requesting they adopt our TERM file name, alacritty. I strongly suspect this to be met with significant pushback. Likely this will be fighting an uphill battle.

Solution 3

Force everyone who relies on dircolors functionality to rely on setting their TERM to xterm-256color in the alacritty.yml file. I personally don’t like this approach because I experience coloring issues when I use a different TERM. However, it is undeniably the easiest, as it just requires closing this issue.

iicurtis on Mar 25, 2019

Changing Alacritty’s TERM to match some arbitrary list of TERMs also doesn’t make much sense at all.

The question why Alacritty requires its own TERM should really always be the other way around, there’s very little reason why any terminal emulator should use the TERM of another, since that will only cause problems.

Requiring to be in the Fedora repos also seems like an extremely weird restriction, since Fedora is not any more of a ‘default’ Linux distro than many of the other distros that Alacritty is already supported on. Only because some arbitrarily chosen Linux distro doesn’t support a specific terminal emulator, should never mean that a bug in an existing application shouldn’t be fixed.

Generally it just seems mostly to be an opposition to change, rather than the change itself. This is also why I’m not personally interested in driving this discussion forward. I don’t have the time to convince every application developer why they should make their apps work with every commonly used terminal emulator. However if the users interested in these changes are willing to put in this effort, that would be much appreciated of course.

chrisduerr on Jun 16, 2019

OK, I understand. I think it’s best to contact the coreutils folks. @iicurtis Did you try that already?

pschyska on Jun 16, 2019

Thanks! I’ll give it a shot at GNU dircolors. Until then, I’ll set LS_COLORS manually.

iicurtis on Mar 25, 2019

Requiring to be in the Fedora repos also seems like an extremely weird restriction, since Fedora is not any more of a ‘default’ Linux distro than many of the other distros that Alacritty is already supported on.

I was just thinking Fedora adds the TERMs of the packaged terminals to dircolors during packaging, but I was mistaken as they are already present in the upstream (GNU coreutils). If Fedora would have added them, I would have to ask the Fedora coreutils package maintainer to add it. Then there would be grounds to question it when alacritty is not officially packaged (in theory). But I misunderstood the situation.

And no, Fedora shouldn’t be a factor in decision w.r.t. to GNU coreutils.

pschyska on Jun 16, 2019