ls: output has no colors on Alacritty

[BuriedInTheGround]

Environment

• OS: NixOS 24.05.20240916.086b448 (Uakari)
• uutils version: 0.0.27
• Terminal: Alacritty
• Shell: zsh 5.9
• $TERM: alacritty
• $COLORTERM: truecolor

Issue

The ls command never shows colored output when TERM=alacritty.

Below is a screenshot comparing GNU coreutils 9.5 with uutils coreutils 0.0.27, both with option --color=always applied. Note how the output of the first is colored, while the latter is not.

Screenshot (collapsed to save scroll space)

To further prove the point, here is a comparison of the output (of a slightly different command, to keep it smaller) of the two utilities when passed to xxd.

Shell output (collapsed to save scroll space)

❯ /nix/store/gvbxl47zf18ikwdii78pz2avaqizagk6-coreutils-full-9.5/bin/ls --color=always -l | xxd
00000000: 746f 7461 6c20 3132 0a64 7277 7872 2d78  total 12.drwxr-x
00000010: 722d 7820 3220 7369 6d6f 6e65 2075 7365  r-x 2 simone use
00000020: 7273 2034 3039 3620 5365 7020 3231 2031  rs 4096 Sep 21 1
00000030: 313a 3333 201b 5b30 6d1b 5b30 313b 3334  1:33 .[0m.[01;34
00000040: 6d50 6963 7475 7265 731b 5b30 6d0a 6472  mPictures.[0m.dr
00000050: 7778 722d 7872 2d78 2033 2073 696d 6f6e  wxr-xr-x 3 simon
00000060: 6520 7573 6572 7320 3430 3936 2053 6570  e users 4096 Sep
00000070: 2032 3120 3131 3a33 3320 1b5b 3031 3b33   21 11:33 .[01;3
00000080: 346d 5363 7269 7074 731b 5b30 6d0a 6472  4mScripts.[0m.dr
00000090: 7778 722d 7872 2d78 2033 2073 696d 6f6e  wxr-xr-x 3 simon
000000a0: 6520 7573 6572 7320 3430 3936 2053 6570  e users 4096 Sep
000000b0: 2032 3120 3131 3a30 3320 1b5b 3031 3b33   21 11:03 .[01;3
000000c0: 346d 5379 6e63 1b5b 306d 0a              4mSync.[0m.
❯ /nix/store/mi6rsqkw2w03mh56sfm9hjkis5c2bi5i-uutils-coreutils-0.0.27/bin/ls --color=always -l | xxd
00000000: 746f 7461 6c20 3132 0a64 7277 7872 2d78  total 12.drwxr-x
00000010: 722d 7820 3220 7369 6d6f 6e65 2075 7365  r-x 2 simone use
00000020: 7273 2034 3039 3620 5365 7020 3231 2031  rs 4096 Sep 21 1
00000030: 313a 3333 2050 6963 7475 7265 730a 6472  1:33 Pictures.dr
00000040: 7778 722d 7872 2d78 2033 2073 696d 6f6e  wxr-xr-x 3 simon
00000050: 6520 7573 6572 7320 3430 3936 2053 6570  e users 4096 Sep
00000060: 2032 3120 3131 3a33 3320 5363 7269 7074   21 11:33 Script
00000070: 730a 6472 7778 722d 7872 2d78 2033 2073  s.drwxr-xr-x 3 s
00000080: 696d 6f6e 6520 7573 6572 7320 3430 3936  imone users 4096
00000090: 2053 6570 2032 3120 3131 3a30 3320 5379   Sep 21 11:03 Sy
000000a0: 6e63 0a                                  nc.

Moreover, enforcing TERM=xterm-256color (or any value like TERM=xterm*) shows a colored output, although colors are not the same as those of GNU coreutils ls. See the screenshot below.

Screenshot (collapsed to save scroll space)

Analysis

Premise: I am not very familiar with Rust (not yet, alas).

Looking around for a root cause in the codebase, I've identified that the extract_color function is responsible for getting the value of the --color option. The first thing the function does is invoking is_color_compatible_term which looks up if the value of $TERM is in this list here. The list does not include alacritty which indeed seems to be the root cause.

To make a comparison, I quickly installed and tried also with Kitty. Since Kitty sets TERM=xterm-kitty, i.e. a xterm* type of value for $TERM, the colors do indeed appear (because of this match in the list).

Suggested solution

Since Alacritty do support colors (see its terminfo), I think it's totally safe, and desirable, to simply add alacritty to the list of compatible terminals. I clearly see that the list is taken directly from dircolors --print-database (or equivalent) but I do think it's fine to diverge in a sensible way like this. Actually, I'd suggest including alacritty*, instead of simply alacritty, so that alacritty-direct and alacritty+common are also supported.

If this simple change it's fine, I'll happily do a PR myself. Just let me know.

[sylvestre]

Sure don't hesitate to submit a pr

[tertsdiepraam]

Amazing bug report!

That would be a pretty good fix, but I wonder whether we even need that list? Might be interesting to investigate why that list was added.

[BuriedInTheGround]

That would be a pretty good fix, but I wonder whether we even need that list? Might be interesting to investigate why that list was added.

Almost the entire content of uucore/src/lib/features/colors.rs seems to derive directly from dircolors --print-database, even comments. If I understand correctly, the problem here (i.e. for uutils ls) is that the choice of whether to colorize or not is based first upon that list from dircolors instead of the LS_COLORS variable. The GNU ls does the latter; see:

• the handling of the --color option;
• the parsing of the LS_COLORS variable, in particular the fact that it only falls back to checking COLORTERM and TERM if LS_COLORS is empty or unset, where the checking of TERM appears to be done with respect to the same list as of uutils (which you won't find directly as code since it is generated).

I'm unable to write high quality Rust to implement a patch that is more faithful to the GNU implementation based on the above, so in the meantime I'll submit the simple PR I suggested earlier.

[lukeflo]

Hi,

its the same problem with foot terminal on a Wayland compositor:

OS: Void Linux x86_64 Terminal: foot $TERM: foot $COLORTERM: truecolor coreutils: 0.0.28

The solution should be the same as for alacritty I guess. Maybe @BuriedInTheGround could add also foot to the list in his PR #6725

[BuriedInTheGround]

Hi @lukeflo.

I can update my PR for sure. However, I'm going to be pretty busy the next few days, so I can't do it right away.

I'll tag you when I'm done so you can check if the fix works for you.

[lukeflo]

@BuriedInTheGround Allright, that would be great. No need to hurry GNU coreutils still work fine 😉