On 7/14/20 4:27 PM, Mantas Mikulėnas wrote:
On Tue, Jul 14, 2020 at 9:48 PM Daan De Meyer <daan.j.demeyer@xxxxxxxxx
<mailto: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.
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 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.
The basic formatting codes (bold, reverse, 8/16-color) are practically the same
everywhere. In fact they're so widespread that many programs and scripts just
straight up hardcode them. (xterm, st, etc. are supersets of vt220/vt421 in that
regard.)
But 256-color or even 24-bit-color codes are not as widely supported. The Linux
VT has only recently started *recognizing* them (though still maps them down to
8 colors). If you use TERM=xterm-256color with Linux VT, apps can look really
weird because you told them they can use these extended color codes even though
they cannot.
Graphical terminal emulators recognize the "update status line" codes (which
goes the X11 window titlebar) -- but the Linux VT has no such thing and the same
code will just show up as garbage on screen.
Google tells me VT421 supported sixel graphics. I'm not sure if any programs
make use of that nowadays, but if they do, then trying to use TERM=vt421 with a
terminal that doesn't do sixel will result in more garbage on screen.
There are various other differences like this.
Boot up logs should target "dumb" terminal only.
So, in the case of boot logs (where we have no idea where messages are going),
if you want "color", I'd use some kind of markup and allow to be interpreted by
whatever is viewing that.
But with regards to logs presumably going to a terminal (real or virtual or
whatever), I'd lean on terminfo and end user selection (which could be by TERM
in the case of an established terminal).
And of course, if it's ok for Dell/HP/IBM to assume Hyperterminal (ansi, 80x25)
for BIOS setup,etc via serial, maybe it's not too far a stretch for Linux to
assume something. But IMHO, if at all possible, I'd make this configurable and
again, lean on terminfo.
Personally I like log data that is parseable. And data with a gazillion escape
sequences is very noisy to look at. Perhaps another reason for some sort of
simple markup instead of escape sequences (?). Hey, our developers are
constantly hard coding ansi-escapes into their log messages so they look
"pretty" in very very specific viewers. Not the way I'd handle it.
_______________________________________________
systemd-devel mailing list
systemd-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
