Most terminal emulators these days set $COLORTERM (in addition to $TERM) to indicate color support. Numerous programs read it (for example coreutils' "dircolors" tool) It seems to be a much more reliable way to detect color support in terminals than $TERM and terminfo/termcap. In fact one might argue terminfo/termcap and $TERM alone is somewhat a failed concept, and $COLORTERM is a much more reliable one (if it is set, and for the little info that it actually conveys). However, $COLORTERM loses its magic when ssh'ing to other hosts: it's not propagated by default... Sniff. Hence, my friendly request: please consider adding something like this to Fedora's default ssh_config: SendEnv COLORTERM (Unfortunately, even though COLORTERM is pretty widely supported these days there's no spec I could find for it) (While you are it, you might as well consider propagating NO_COLOR the same way. As per this spec: https://no-color.org/) (Also note that my own project, systemd, honours both COLORTERM + NO_COLOR for its color output) Reproducible: Always
Also see: https://github.com/termstandard/colors?tab=readme-ov-file#checking-for-colorterm (i.e. i figure on the server config AcceptEnv= should also be updated)
FWIW back in 2012 in Fedora we used COLORTERM to key whether >= 256 colors were supported. See https://fedoraproject.org/wiki/Features/256_Color_Terminals Use of that env var was quite ubiquitous at that time, and at that time we suggested/patched some less popular terminals to also set COLORTERM
I'm quite surprised hearing that there are some problems with colors processing without this variable, speaking frankly. I didn't come across on it for a while. Could you please provide an example when we meet this problem?
Consider this: take a current fedora VM, boot it in qemu with serial console or hvc console, log into the serial/hvc. You'll find TERM=vt220, because we have no better info, this is a reasonable safe fallback that is relatively "modern" but available in everybody's terminfo. If you type "ls" now, you'll see no coloring being used, even though fedora defaults to color. With a git version of systemd however it does work, because it sets COLORTERM=truecolor too, if it defaults TERM=vt220. `ls` cares about $COLORTERM, like a myriad other tools. Except if you then ssh from that machine elsewhere (for example via "localhost" into itself). Because $TERM is propagated, but $COLORTERM is not, if you type `ls` then all the color is gone again. Sniff! "sudo" has been propagating COLORTERM since 2007 because of this. See https://github.com/sudo-project/sudo/commit/f221ba2300ea526192d575bf81db60211b362e15. Many other tools too. ssh unfortunately not though. to emulate the above without actually firing up a VM, try this from your shell: ```sh export TERM=vt220 unset COLORTERM eval $(dircolors) ls / ``` this will show an uncolorized ls. now do: ```sh export TERM=vt220 export COLORTERM=truecolor eval $(dircolors) ls / ``` now it's colorized. to verify that `sudo` propagates COLORTERM: ```sh TERM=vt220 COLORTERM=truecolor sudo -s echo $TERM $COLORTERM eval $(dircolors) ls ``` to verify that `ssh` does not propagate COLORTERM: ```sh TERM=v220 COLORTERM=truecolor ssh localhost echo $TERM $COLORTERM eval $(dircolors) ls ```
FEDORA-2025-49ccf029e9 (openssh-9.9p1-13.fc43) has been submitted as an update to Fedora 43. https://bodhi.fedoraproject.org/updates/FEDORA-2025-49ccf029e9
Excellent! Thank you so much! That was quick! Much appreciated!
FEDORA-2025-49ccf029e9 (openssh-9.9p1-13.fc43) has been pushed to the Fedora 43 stable repository. If problem still persists, please make note of it in this bug report.