When we are talking to a serial terminal quite commonly the dimensions
are not set properly, because the serial protocol has not handshake or
similar to transfer this information.
However, we can derive the dimensions via ANSI sequences too, which
should get us the right information, since ANSI sequences are
interpreted by the final terminal, rather than an intermediary local tty
driver (which is where TIOCGWINSZ is interpreted).
This adds a helper call that gets the dimensions this way.
Let's prefix these functions with the subsystem name, and clean them up
a bit. Specifically, drop the error logging, it's entirely duplicative,
since every single caller does it anyway.
- introduce or rename usual enum values _MAX and _INVALID,
- introduce and use string table lookup functions,
- split out implementation of get_color_mode() to _impl(),
- add tests for get_color_mode().
Doing this in reset_terminal_fd() is a bit too invasive, see
https://github.com/systemd/systemd/pull/32406#issuecomment-2070923583.
Let's only do this for /dev/console so that we work around weird firmwares
disabling line-wrapping, but avoid messing too much with other things.
While we're at it, let's handle more than just line wrapping, and do a
more general reset of stuff to get the terminal into a sane state.
We shouldn't try to use any ANSI escape sequences if TERM=dumb.
Also, the "\r\n" we output can get interpreted as a double newline
(for example by Github Actions), so let's output just "\n" when
TERM=dumb to clean up the CI logs.
So if we tint the background of a ptyfwd session with a color and the
session ends, then so far we reset the bg color and clear till the end
of line.
Let's instead clear till the end of the screen. This is nicer since it
means that any follow-up output will not be affected by the changed
background color anymore.
This is different from the existing macros that generate "underline"
ANSI sequences: these ones are additive, i.e. do not reset the font to
the default first. The idea is to combine these with other ansi
sequences.
We currently concatenate ANSI_UNDERLINE to the color of our choice
in DEFINE_ANSI_FUNC_UNDERLINE() and DEFINE_ANSI_FUNC_UNDERLINE_256().
The first thing that ANSI_UNDERLINE does is reset all previous ansi
escape sequences, so you just get underlining without any colors.
Let's fix the issue by actually concatenating _UNDERLINE to the given
color macro name so this works properly.
Also add missing color macros that this uncovered.
As suggested in https://github.com/systemd/systemd/pull/11484#issuecomment-775288617.
This does not touch anything exposed in src/systemd. Changing the defines there
would be a compatibility break.
Note that tests are broken after this commit. They will be fixed in the next one.
This commit extends $SYSTEMD_COLORS to an enum variable (compared to
a simple boolean) which specifies the "colors mode". This means that, in
addition to disabling colors altogether, it's now possible to restrict
the console output to 16 or 256 colors only.
We would add and remove definitions based on which colors were used by other
code. Let's just define all of them to simplify tests and allow easy comparisons
which colors look good.
non-underlined yellow uses RGB ANSI sequences while the underlined
version uses the paletted ANSI sequences. Let's unify that and use the
RGB sequence for both cases, so that underlined or not doesn't alter the
color.
Allocating a pty is done in a couple of places so let's introduce a new helper
which does the job.
Also the new function, as well as openpt_in_namespace(), returns both pty
master and slave so the callers don't need to know about the pty slave
allocation details.
For the same reasons machine_openpt() prototype has also been changed to return
both pty master and slave so callers don't need to allocate a pty slave which
might be in a different namespace.
Finally openpt_in_namespace() has been renamed into
openpt_allocate_in_namespace().
Only changing ownership back to root is not enough we also need to
change the access mode, otherwise the user might have set 666 first, and
thus allow everyone access before and after the chown().
Previously used "highlight yellow" was not visible on urxvt, because it
was too light. This color is shown as bold black by urxvt, but at least
it is readable. On other terminals it is shown as various hues of yellow,
pleasant on the eyes and not too bright. The color shown on linux console
could be called orange rather than yellow, but it is still readable.
(I also tried non-highlight "yellow", but it is not as readable.)
This is a follow-up for bb40c12569.
We don#t actually use all combinations, but it's kinda nice if we can
output all combinations in a test, and this is preparation so that we
can do so nicely.
three of these colors we never use, so let's drop them. Let's however
add a highlight version of grey, so that at least for all colors we do
define we have all possible styles defined.
Apparently all relevant terminals implement these sequences, including
the Linux kernel, rxvt, xterm, and of course gnome terminal. Hence it
should be OK to use them, and fixate the grey color in a way that maps
to the same color in all terminals.
Ideally we'd stick to the more symbolic colors that allow terminal
emulators to implement color styles, but this apparently doesn#t work,
since rxvt maps grey to something unreadable by default.
Note that this change has negative effects besides the non-themability
of the palette: the midrange grey this uses maps to regular white on the
linux console. However, that's probably not too bad: allowing things to
be unreadable on some terminals is probably worse than showing no color
on some terminals.
Fixes: #12482
Lennart Poettering
Yu Watanabe
Zbigniew Jędrzejewski-Szmek
Daan De Meyer
Mike Yuan
OMOJOLA JOSHUA
Sonali Srivastava
rnhmjoj
Franck Bui
Balint Reczey