> 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
> 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).
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.
Thanks for all the info as well. It's always fun to read how stuff was done back in the early days.
Daan
On Tue, 14 Jul 2020 at 21:04, Christopher Cox <ccox@xxxxxxxxxxxxxx> wrote:
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 <ccox@xxxxxxxxxxxxxx
> <mailto:ccox@xxxxxxxxxxxxxx>> wrote:
>
> On 7/14/20 3:19 AM, Lennart Poettering wrote:
> > On Mo, 13.07.20 18:16, Christopher Cox (ccox@xxxxxxxxxxxxxx
> <mailto:ccox@xxxxxxxxxxxxxx>) 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: http://terminals-wiki.org/wiki/index.php/DEC_VT240
> >>
> >> 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
> systemd-devel@xxxxxxxxxxxxxxxxxxxxx <mailto:systemd-devel@xxxxxxxxxxxxxxxxxxxxx>
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
>
_______________________________________________
systemd-devel mailing list
systemd-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
_______________________________________________ systemd-devel mailing list systemd-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/systemd-devel
