<div dir="ltr">> About your other comments, systemd sits in user space and can query (depend > upon) terminfo. Then, it should be able to support "whatever" terminfo has > defined.... which could include custom terminals by the way that an end user has > added. And while all of that sounds incredibly ancient/old, I was on a project <div>> post 2000 that had to do exactly that (of course, even that might sound too old).</div><div> </div><div>Interestingly enough, systemd's colors work even when TERM is set to vt220, probably because it uses ansi escape codes regardless of the TERM setting. I think there's probably lots of applications doing this except for ls in coreutils which has an explicit list of terminals with color support encoded in the dircolors configuration file. If TERM isn't one of those, you don't get colors. There's probably others that do this as well. I don't think changing the default in systemd is a good idea since it might break other stuff. I'm going to submit a mkosi PR instead that adds an option that overrides serial-getty@ttyS0 with whatever terminal the user wants. Colors won't work out of the box but at least it shouldn't be too hard to find out how to get them to work when using mkosi.</div><div> </div><div>Thanks for all the info as well. It's always fun to read how stuff was done back in the early days. </div><div> </div><div>Daan </div></div> <div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 14 Jul 2020 at 21:04, Christopher Cox <<a href="mailto:ccox@endlessnow.com">ccox@endlessnow.com</a>> wrote: </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 7/14/20 1:48 PM, Daan De Meyer 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. So, some info (not necessarily direction). Old guys like to talk... So, speaking of things of old, but not ancient old, when handling server equipment via serial, you normally do three things. You route the BIOS (legacy) out the serial port, you send the kernel boot messages out the serial port and you establish a getty for login on the serial port. Just being honest, the "server world" decided everything was Microsoft Hyperterminal (up to Windows XP, what many considered to be "ansi", 80x25) during the PC revolution. So.. Windows doesn't come with Hyperterminal anymore, which makes sense since PCs in general don't have serial ports (apart from USB-serial dongles). So, can you, or should you adopt a serial console solution (ansi, 80x25)? IMHO, this is still interesting. Especially in the Linux world. Consider that network equipment still speaks serial for console, the concept (still, even though this in a old concept) of using, for example, ssh to serial console controllers for full out of band access might still be appealing. Why? Well, for many reasons. Cabling is much less (that is, less dense) as you can use flat velum for quite some distance for serial. Since you're having to somehow deal with network devices anyway, by have all done serially, you have "one stop" shopping for out of band (more on this in a bit) console access. Bonus, no high cost of licensing, for example, iLO or iDrac ent. But noting that you don't get virtual media with a serial console head solution either. But still, if running remote facilities and you need true out of band, and by that I mean the ability to reconfigure everything, including the network, it could be just the thing you need. But ssh? Network reconfigure? That's not going to work. Often times those same ssh to serial console devices have additional serial support usually with a option of a modem (yep... old school I know). Back in the day, using a callback modem (added security) your infrastructure could reach out to you and you could indeed reconfigure the whole datacenter, soup to nuts. Something lacking in general today. About your other comments, systemd sits in user space and can query (depend upon) terminfo. Then, it should be able to support "whatever" terminfo has defined.... which could include custom terminals by the way that an end user has added. And while all of that sounds incredibly ancient/old, I was on a project post 2000 that had to do exactly that (of course, even that might sound too old). Btw, as weird as it sounds, where I work today, and I'm not the network admin, the network admin has purchased a ssh to serial console controller with callback modem. And he's in his early 30's. Btw, when I used to help manage an entire datacenter (same time as contract below) with those ssh to serial controllers, I just let the the linux TERM remain as it was mostly compatible with the ANSI from the host BIOS (at least I'm pretty sure). With regards to that post 2000 project, I was interfacing with an old accounting package called datamodes. Company wanted a solution where by people at home could ssh into this character based gui, have all the key sequences (and I do mean all, every Fn, Ctrl, Shift, Alt combo) and have the ability to print to their local printers from that ssh terminal session. All of this was doable with good old fashioned terminal handling from the ancient of days. But I did have to craft my own terminfo entry. Loosely based off the scoansi terminal (one of the most complete terminal definitions out there, but not totally complete). The end users were already running a terminal emulator that had a SCO ansi mode. (even back then, datamodes had a "Windows" solution, but for the company I was contracting to, it was too expensive) > > Daan > > On Tue, 14 Jul 2020 at 18:22, Christopher Cox <<a href="mailto:ccox@endlessnow.com" target="_blank">ccox@endlessnow.com</a> > <mailto:<a href="mailto:ccox@endlessnow.com" target="_blank">ccox@endlessnow.com</a>>> wrote: > > On 7/14/20 3:19 AM, Lennart Poettering wrote: > > On Mo, 13.07.20 18:16, Christopher Cox (<a href="mailto:ccox@endlessnow.com" target="_blank">ccox@endlessnow.com</a> > <mailto:<a href="mailto:ccox@endlessnow.com" target="_blank">ccox@endlessnow.com</a>>) wrote: > > > >>> No vt220 does not support colour. I used to work on one and it is > >>> monochrome hardware. > >>> Xterm and konsole support extensions beyond vt220 that add in the > colour support. > >> > >> Not sure how much (offtopic) history we want to get into. I used the VT240 > >> in my college graphics class. The VT241 was the color variant. > >> > >> See: <a href="http://terminals-wiki.org/wiki/index.php/DEC_VT240" rel="noreferrer" target="_blank">http://terminals-wiki.org/wiki/index.php/DEC_VT240</a> > >> > >> I still meet programmers what hard code ansi sequences rather than querying > >> termcap/terminfo. You know what they say about those who "assume". > > > > Hmm, if vt241 is a bettre featured terminal type, and both xterm and > > the Linux console a superset of it, and the terminal widely available > > in termcaps and stuff we can certainly change our default TERM to be > > vt241. > > > > Daan, if this all is the case, could you prep a PR? > > I would think shooting for something low is actually good. Let the individual > configure for something "better". > > I'm not sure I'm ready to say monochrome is obsolete. There can be beauty in > simplicity and function. My preference, aim low, and allow easy configuration > upward. You could take the opposite stance of course, it's just that it could > cause some frustration. > > Just my opinion though. I'm old and I think about a lot of things like > terminals, "proxies" and callback modems... things of value, but most do not > understand or care about anymore. > > > _______________________________________________ > systemd-devel mailing list > <a href="mailto:systemd-devel@lists.freedesktop.org" target="_blank">systemd-devel@lists.freedesktop.org</a> <mailto:<a href="mailto:systemd-devel@lists.freedesktop.org" target="_blank">systemd-devel@lists.freedesktop.org</a>> > <a href="https://lists.freedesktop.org/mailman/listinfo/systemd-devel" rel="noreferrer" target="_blank">https://lists.freedesktop.org/mailman/listinfo/systemd-devel</a> > _______________________________________________ systemd-devel mailing list <a href="mailto:systemd-devel@lists.freedesktop.org" target="_blank">systemd-devel@lists.freedesktop.org</a> <a href="https://lists.freedesktop.org/mailman/listinfo/systemd-devel" rel="noreferrer" target="_blank">https://lists.freedesktop.org/mailman/listinfo/systemd-devel</a> </blockquote></div>