From: Lennart Poettering Date: Mon, 17 Mar 2025 08:34:49 +0000 (+0100) Subject: exec: when we have no $TERM configuration, and we default to vt220, also set $COLORTERM X-Git-Tag: v258-rc1~1063^2~2 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=728dbaeffb3e72872253c50ca5d1c100cc532634;p=thirdparty%2Fsystemd.git exec: when we have no $TERM configuration, and we default to vt220, also set $COLORTERM When we configure a serial or VM terminal and have no $TERM configuration, then we default to vt220 as a fallback. This is a pretty safe bet, since the termcap/terminfo definitions for vt220 are relatively widely available (much like vt100), and (in contrast to vt100) it supports pageup/pagedown keys. vt220 is a terminal without color support however, but we do want color support, because in 2025 there's really no terminal emulator without color in this world. The $COLORTERM env var is used my many emulators and tools to communicate that ANSI color support is available, despite what $TERM says. Hence, let's tweak systemd's logic to also set $COLORTERM in case we set the vt220 $TERM fallback. This means we define an ahistoric frankenterminal: a vt220 (that historically definitely didn't have color) that is explicitly configured to have color. One effect of this is that coreutils' dircolors command will start to output color sequences in systemd's serial or VM terminals. (Since it actually honours $COLORTERM). Also note that systemd itself checks $COLORTERM since a long time, hence it makes sense for us to also set it. Note that this unfortunately doesn't have the desired effect of propagating $COLORTERM into any getty shell sessions yet. That's because util-linux' login package currently fiters $COLORTERM (but lets $TERM though). I filed a bug about that here: https://github.com/util-linux/util-linux/issues/3463 --- diff --git a/src/core/exec-invoke.c b/src/core/exec-invoke.c index 2cee136feeb..6bb4584a8ee 100644 --- a/src/core/exec-invoke.c +++ b/src/core/exec-invoke.c @@ -1912,7 +1912,7 @@ static int build_environment( assert(cgroup_context); assert(ret); -#define N_ENV_VARS 20 +#define N_ENV_VARS 21 our_env = new0(char*, N_ENV_VARS + _EXEC_DIRECTORY_TYPE_MAX); if (!our_env) return -ENOMEM; @@ -2048,8 +2048,28 @@ static int build_environment( term = cmdline; } - if (!term) + if (!term) { + /* If no precise $TERM is known and we pick a fallback default, then let's also set + * $COLORTERM=truecolor. That's because our fallback default is vt220, which is + * generally a safe bet (as it supports PageUp/PageDown unlike vt100, and is quite + * universally available in terminfo/termcap), except for the fact that real DEC + * vt220 gear never actually supported color. Most tools these days generate color on + * vt220 anyway, ignoring the physical capabilities of the real hardware, but some + * tools actually believe in the historical truth. Which is unfortunate since *we* + * *don't* care about the historical truth, we just want sane defaults if nothing + * better is explicitly configured. It's 2025 after all, at the time of writing, + * pretty much all terminal emulators actually *do* support color, hence if we don't + * know any better let's explicitly claim color support via $COLORTERM. Or in other + * words: we now explicitly claim to be connected to a franken-vt220 with true color + * support. */ + x = strdup("COLORTERM=truecolor"); + if (!x) + return -ENOMEM; + + our_env[n_env++] = x; + term = default_term_for_tty(tty_path); + } x = strjoin("TERM=", term); if (!x)