Re: vt220 default for serial console still relevant?

[Lennart Poettering <lennart@xxxxxxxxxxxxxx>]

On Di, 14.07.20 19:48, Daan De Meyer (daan.j.demeyer@xxxxxxxxx) wrote:

> I just tried vt241 and didn't get colorized output in konsole. I looked
> around a bit and it doesn't really seem supported at all by terminal
> emulators (or at least none that I found). I also tried TERM=xterm-256color
> with 8 different terminal emulators and got colors with all of them. My
> workflow is simply "mkosi qemu -nographic" (with a modified mkosi that adds
> console=ttyS0 and overrides TERM for serial-getty@ttyS0 in the vm)." That
> connects my terminal emulator to the serial console of the vm. I then
> execute "ls -l --color /" in the vm and get colored output every time in
> whatever terminal emulator that I try.

Well, --color means you request color no matter what, so this is not surprising.

> I'm probably missing something but I'm wondering what an example terminal
> emulator would be where xterm-256color would not work at all (even st
> worked perfectly and that is supposed to be pretty barebones
> afaik). Or is

xterm-256color is a relatively "recent" definition, actually.

The thing is that xterm has ton of extensions in the set of ANSI/CSI
sequences that for example the Linux console does not have. Hence it
sucks advertising the Linux console as xterm. Similar, the Linux
console has a lot of different semantics and features beyond
xterm. And even besides the command set there's other stuff context
derived from the terminal setting. For example in systemd we disable
emojis if TERM=linux is set, since we know that the linux console has
only mininmal unicode support, i.e. 512 glyphs at max, and emojis are
almost certainly not among them. Terminals after all don't advertise
the set of glyphs they can display, so the second best thing is to
trust TERM=linux. (We also turn off emojis on TERM=dumb)

> it just that color is a commonly supported subset of xterm and stuff breaks
> down with other escape codes instead? Or maybe qemu is doing some kind of
> translation that magically makes every TERM setting work in whatever
> terminal emulator I try? Apologies if this seems ignorant, I have no
> experience at all with this domain.

Pretty much all current terminal emulators support color just
fine. It's really old legacy hw terminals that don't support that.

In systemd we don't really care much about super old terminal support,
i.e. we never consult termcap/terminfo about terminals, because we
don't want to require that to be installed. Instead, we assume that
terminals can do color, except if TERM=dumb is set, it's 2020 after
all. We also assume they can do full Unicode, except if LC_CTYPE is
configured and explicitly indicates otherwise. We assume they can do
emojis, except if TERM=linux or TERM=dumb is set where we know it's
not supported. And we assume that hyperlinks work (except if "less" is
involved). I think assuming this all to just work on any recent
terminal is pretty safe in 2020. Of course this means we might
mistakenly output color sequences to a 1980's terminal if you actually
connect that, but besides some exotic hackers noone does that anymore,
hence we don't really care (and noone ever filed a bug about
that). You can turn off color, unicode, emoji support individually via
env vars btw, if people really want compat with such old terminals.

Lennart

--
Lennart Poettering, Berlin
_______________________________________________
systemd-devel mailing list
systemd-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/systemd-devel