Fedora Account System
Red Hat Associate
Red Hat Customer
shell-color-prompt seems to enable itself only if $TERM is set to "linux" or if it ends in "-color". I think that's too narrow. There are a myriad of terminal emulators out there, and pretty much all of them do understand color, even if they set $TERM to arbitrary values. In systemd, if we really have no idea about what $TERM is right for a serial terminal (which is the common case in VMs) we set it to our default fallback vt220. Now strictly speaking vt220 never supported color, but nonetheless most tools generate color anyway these days. vt220 has the benefit that it is installed pretty much in any version of the terminfo/termcap database, and supports various special keys such as pageup/pagedown, which makes it a really safe bet, and hence is our fallback. A tool that famously generates color output is coreutils' `dircolors` tool which allowlists `vt100` for color, even though vt100 definitely never supported color. I'd like to suggest to invert the tests in shell-color-prompt: enable color output by default except if: 1. TERM=dumb is set, making clear that no ANSI sequences are supported 2. NO_COLOR is set, which should just turn off color. This follows this spec: https://no-color.org/ That's the logic that systemd itself implements for all its own color output. And so far complaints have been absent. (we had some complaints years ago before we added support for NO_COLOR, but since then people who actually use 1983 hardware terminals just set NO_COLOR and are happy).
Oh, totally forget: we nowadays also check for $COLORTERM, which various terminal emulators these days set, to indicate their color support. There is no nice spec, but it's widely supported, including in systemd. (i.e. add a 3rd item to the list above)
Thanks for the suggestions
*** Bug 2333485 has been marked as a duplicate of this bug. ***
I think I agree with your thoughts - I started this new feature cautiously to avoid upsetting any users. One further reason is that the actual colors vary widely from terminal to terminal so it is really hard to come up with ideal defaults that work well everywhere... Anyway we can try to enable it more widely I guess - I will leave my flame-suit by my desk just in case, ;o) Also I was not aware of NO_COLOR that helps indeed. I will add COLORTERM too, thanks. I aim to do this very soon for the next release after 0.6, which I am about to push (I have had lying around now for a year now in my local repo... oh dear).
> shell-color-prompt seems to enable itself only if $TERM is set to "linux" or if it ends in "-color". Yes testing various terminals, it feels like $COLORTERM (instead of TERM with "-color") should probably unlock 95%+ of color terminals.
Implemented in 0.7 which I am pushing to Rawhide now. Perhaps after a period it could even be backported to F42 possibly, but let's see.
A few more details about the current changes: - https://src.fedoraproject.org/rpms/shell-color-prompt/c/c3eb4d2a9cb061a8c0101f2352160707b44615db?branch=rawhide contains the COLORTERM/dumb change - https://src.fedoraproject.org/rpms/shell-color-prompt/c/f998ab3373333d34dd9ef93c26f23051264f7bf9?branch=rawhide contains the NO_COLOR change However here is an example of regression caused by TERM != "dumb" I believe: For the server_cockpit_basic@64bit test https://openqa.fedoraproject.org/tests/3466363 (0.6.1) vs https://openqa.fedoraproject.org/tests/3513042 (0.7) you can see ansi garbage on the serial console prompt now. So I will revert "!dumb" back to "*color" or "linux" for now, but of course keep the COLORTERM test.
@mzeuom btw you didn't mention which terminal you hit this on... I am happy to consider how to support more use-cases like say WSL or others etc if needed. Though hopefully COLORTERM will already help here. At least backporting that to F42 might make sense, since it is a smaller change.
Though perhaps we could avoid the serial console somehow... I wonder how systemd handles it.
(Anyway the main "casuality" I am aware of so far is lterm, which I had never seen or used until yesterday.) I pushed shell-color-prompt-0.7.1 for Rawhide now. Also added https://src.fedoraproject.org/rpms/shell-color-prompt/blob/rawhide/f/TERMCOLOR.txt which may be a useful reference.
(BTW I may need to retest the results in TERMCOLOR.txt, since I erroneously ran most of the terminals from a terminal that exported COLORTERM...)
(In reply to Jens Petersen from comment #11) > (BTW I may need to retest the results in TERMCOLOR.txt, since I erroneously > ran most of the terminals from a terminal that exported COLORTERM...) I retested most of them to be sure and they are actually fine (assuming TERMCOLOR is not set on the desktop).
(In reply to Lennart Poettering from comment #0) > In systemd, if we really have no idea about what $TERM is right for a serial > terminal (which is the common case in VMs) we set it to our default fallback > vt220. Now strictly speaking vt220 never supported color, but nonetheless > most tools generate color anyway these days. vt220 has the benefit that it > is installed pretty much in any version of the terminfo/termcap database, > and supports various special keys such as pageup/pagedown, which makes it a > really safe bet, and hence is our fallback. Okay you did specifically mention serial console here I guess? However from what I saw in fedora openQA results it causes ansi garbage for the root prompt: see the earlier openqa url in comment 7.
For additional context, see https://github.com/systemd/systemd/issues/36994 and https://github.com/systemd/systemd/pull/37538. We added code to use ANSI DCS sequence to detect the terminal type. This means that the previously-hardcoded TERM=vt220 is used only when that is not supported. Currently, support is not widespread, e.g. foot, kitty, xterm have it, but gnome-terminal and a few other common emulators do not. This code is not released yet. It should become available in rawhide in v258-rc1, probably in 2–3 weeks from now. If ANSI DCS becomes widely supported, then $TERM should become mostly trustworthy and the need to try to guess the "real" value will go away.
Reopening for F42 backport
FEDORA-2025-5ae683400d (shell-color-prompt-0.7.1-1.fc42) has been submitted as an update to Fedora 42. https://bodhi.fedoraproject.org/updates/FEDORA-2025-5ae683400d
FEDORA-2025-5ae683400d has been pushed to the Fedora 42 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2025-5ae683400d` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2025-5ae683400d See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2025-5ae683400d (shell-color-prompt-0.7.1-1.fc42) has been pushed to the Fedora 42 stable repository. If problem still persists, please make note of it in this bug report.