From: Lennart Poettering Date: Mon, 17 Mar 2025 12:17:06 +0000 (+0100) Subject: better support for $COLORTERM (#36770) X-Git-Tag: v258-rc1~1063 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=0201114bb7f347015ed4d85256637921dc304fe0;p=thirdparty%2Fsystemd.git better support for $COLORTERM (#36770) I recently noticed that our serial/VM terminals did not get fedora's color shell prompt, nor got color support in "ls". I spend a bit of time investigating and it's all a bit of a mess. If we don't have any idea what kind of terminal we are talking to via serial or hypervisor console then we so far just set TERM=vt220 as a reasonable fallback: vt220 is quite universally defined in terminfo/termcap, and it supports pageup/pagedown (unlike vt100). However, real vt220 DEC terminals did not support color, and hence termcap/terminfo says "no color, sorry". Which sucks, but actually neither coreutils' "ls" (via `dircolors`) nor fedora's color shell prompt actually care for termcap/terminfo. So why don't we get color? In the coreutils case: it has it's own mini-database of terminals. A very skewed one, where TERM=vt100 enables colors (and DEC vt100 definitely never ever had color support!), but vt220 does not. However, what it actually does is check $COLORTERM. If that's set then it would enable color. In the fedora color prmpt case: it tries to derive color support by looking for the word "color" in $TERM. Horrible hack if you ask me... In order to make things better I did a bunch of things: 1. I think the idea of actually having a fully correct and up-to-date termcap/terminfo database is kinda illusionary these days. But apparently regarding color support $COLORTERM kinda took it place. coreutils cares, and systemd itself cares too. To some point at least: we consume it to determine color support, but we never propagate it in nspawn, run0 and so on. So this PR fixes that. 2. Also, we are kinda stuck with vt220 I guess as default fallback for serial terminals. But let's tweak it, and set $COLORTERM=truecolor as default too. this means we default to a vt220 terminal, but with color. Which is an ahistorical thing to do, but I think it's the best way out. 3. I also filed a bug against util-linux asking them to treat $COLORTERM like $TERM, and let it propagate from getty into login shell: https://github.com/util-linux/util-linux/issues/3463 – With that we should get color support in ls by default now. 4. I also asked coreutils to treat vt220 the same as they already treat vt100 and simply do color, even if though that's ahistorical: https://github.com/coreutils/coreutils/issues/96 5. I then asked the fedora color prompt package to check $COLORTERM: https://bugzilla.redhat.com/show_bug.cgi?id=2352650 6. I also asked the fedora ssh package to propagate $COLORTERM to remote hosts by default, like they already cover $TERM. terminal emulators set both these days generally, hence this would make sense. https://bugzilla.redhat.com/show_bug.cgi?id=2352653 7. while at it, I figured it makes sense to not only propagate/consume $COLORTERM at the same time as $TERM, but also consider $NO_COLOR. In contrast to $COLORTERM for which no spec seems to exist, that one actually does have a spec: https://no-color.org/ It might make sense for those interested in other distros than Fedora to maybe ask for similar changes for their ssh and color shell prompt packages (if they have something coresponding). --- 0201114bb7f347015ed4d85256637921dc304fe0