On Wed, Jul 09, 2025 at 06:23:19PM +0200, Ingo Schwarze wrote:
> Hello,
> 
> Theo de Raadt wrote on Wed, Jul 09, 2025 at 08:58:39AM -0600:
> > Stuart Henderson <stu@spacehopper.org> wrote:
> >> On 2025/07/08 18:18, Ingo Schwarze wrote:
> 
> >>> I see.  Maybe the world is slowly, very slowly, moving towards a state
> >>> where termcap/terminfo becomes obsolete (wouldn't be surpring; actual
> >>> hardware terminals obviously aren't common any more).  If that happens,
> >>> some standard might eventually emerge, and likely TERM=xterm is the
> >>> closest we have so far to such a standard...
> 
> >> A disappointing amount of console based software aimed at unix-like
> >> systems is just hardcoding ECMA-48 type escape sequences these days :(
> 
> > We can fight against the trend, or we can fight in the same direction
> > as the trend.
> 
> These two options are not even mutually exclusive.
> We can aim to support a sane subset of ISO/IEC 6429 in our terminals
> and consoles, yet correctly use termcap/terminfo in our own software
> as long as termcap/terminfo still exists.

This is exactly what we are doing.

Until I started sending these wscons patches at the end of 2022, wscons was
basically superset of a subset of vt220 emulation.  In fact, it's always been
quite far removed from a real vt220.

_None_ of the terminfo entries worked correctly on the console.

vt220 was and is broken, as the F1 - F4 keys are incorrectly mapped amongst
other things, and there is no support for colour because real vt220s don't do
colour.

pccon was broken in various ways.  The ncv#2 entry prevents use of colour and
underline at the same time, which might have made sense for VGA text mode,
but we're in 2025 now and things have moved on.  The op parameter resets to
black text on white, which is unexpected for users who didn't grow up with
the sparc console.  Other control sequences are also missing.

So it was impossible for software that parsed termcap/terminfo to fully use
the functionality that was present.

As Stuart points out, a lot of software just assumes that it's running on an
ECMA-48 capable display.  And ironically, that software just worked.  It also
almost certainly works in a real xterm and on the linux framebuffer console,
because these control sequences are supported on virtually all vaguely modern
terminal emulators.

At this point, the obvious, (to me), terminfo entry to target was xterm,
because why not?  Any recent OS that has a terminfo file at all is going to
have a good quality terminfo entry for xterm, because it's what people use
and they expect it to work.

So our compatibilty with xterm in the most part really means compatibilty
with the xterm terminfo entry.

Now bearing in mind that xterm is itself basically a superset of vt220, this
doesn't create much of a problem in terms of backwards compatibility.

Almost anything that worked on a vt220 should work just fine on xterm, and by
extension, 99% of those can work on a minimal implementation of xterm control
sequences implemented in wscons.  As Theo pointed out - people are already
doing this, and I don't see misc overflowing with complaints that things have
broken.

But at the moment we are only part of the way there.  I am fairly confident
already that TERM=xterm will not break many user's systems.  But maybe there
are a few xterm control sequences that we don't implement yet that are indeed
in common use.  We need to find out.

We also want to remove vt220 bits that are not required or useful for xterm
compatibility, as it makes no sense to carry around vestigial support for
something that we are no longer claiming to support and which we never really
fully supported anyway.

The complication here is that since xterm is a superset of vt220, what can we
get rid of?  Surely nothing, right?

Well, from a pedantic point of view, maybe.  But consider this detail:

There are sequences that a real vt220 responds to which only serve to indicate
that it is a vt220, and to report it's configuration.  Xterm does honour these
enquiries and wscons implements some of them too.

But modern software absolutely shouldn't be relying on probing the console to
find out what it is.  Exactly because there are tonnes of terminals out there
which are NOT vt220s, but which happily reply and claim that they are.

Modern software should be using a method external to the actual terminal
connection to set it's view of the terminal type, and on a unix like system,
that is basically going to be terminfo/termcap, or manual user configuration,
or just assuming that ECMA-48 sequences work.

Now, if and only if you are telnetting in to a VMS box, or a TOPS-10 machine,
then maybe you might reasonably expect it to set the terminal type by probing
the terminal itself with control sequences.

For the handful of OpenBSD users that are using systems like that, the
solution is to install a more capable terminal program.  Otherwise wscons
would have to expand support everything that ever existed, and I'm not
particularly excited about adding EBCDIC support just in case somebody one day
needs it.

For this reason I sent a patch the other day that removes some vestigial code
from wsemul_vt100_subr.c that I'm pretty confident nobody will miss.  It
would be nice to get that in so we can start trimming the stuff that somebody
might just care about.