Note there is an easy way to override term type. The default serial-getty@.service at least here has no TERM set by default, but uses it to set term type when launching getty. You can use kernel command line and add TERM=screen for example, or things like that, and it should be picked up, shouldn't it? W dniu 15.07.2020 o 00:44, Christopher Cox pisze: > 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
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ systemd-devel mailing list systemd-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/systemd-devel
