>>> Lennart Poettering <lenn...@poettering.net> schrieb am 15.07.2020 um 18:08 in Nachricht <20200715160804.GB182602@gardel-login>: > On Di, 14.07.20 19:48, Daan De Meyer (daan.j.deme...@gmail.com) 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
Just two thoughts on this: I think as bloated as systemd already is, reading termcap or terminfo would not make a big difference. More an issue is that termcap and terminfo are competitors boing basically the same (AFAIK). The other thing is that you are assuming a mono-culture, specifically that all terminals understand the same control sequences as vt100/ansi. That applies for Linux and xterm, because they are modeled after vt100. But, for example a vt52 has a completely different set of control commands. > 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. I just don't like monocultures... Regards, Ulrich > > Lennart > > ‑‑ > Lennart Poettering, Berlin > _______________________________________________ > systemd‑devel mailing list > systemd‑de...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/systemd‑devel _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
