Re: tn3270, mset and map3270

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Wed, 10 Feb 2010 08:18:59 +0200
    From:        Alan Barrett <apb%cequrux.com@localhost>
    Message-ID:  <20100210061858.GB1233%apb-laptoy.apb.alt.za@localhost>

  | In your first case, whether or not the system has writable media is
  | irrelevant.  The idea is to let things Just Work through remote login
  | sessions or terminal emulators that export the TERMCAP environment
  | variable, giving users the convenience of not having to create
  | persistent termcap/terminfo descriptions on the remote system.  I
  | don't actually use this feature myself, and I don't know whether it's
  | a real or hypothetical case;

I used to do that - my remote login scripts would pass through stuff
like TERMCAP (also the current settings for erase, kill, etc) when
connecting to a remote system (this was in rsh days of course, but
I can't think of a reason it wouldn't work with ssh if needed).

But I haven't needed any of that for years now, I can't remember the
last time I used a 5620, or a vc404, or a tek4014, or whatever - everything
these days is a software terminal emulator, and they all (or all the useful
ones) pretend to be ANSI equivalent (vt100 or better).

With that in mind, what's been happening with termcap/terminfo is
probably the wrong solution - the very reason that we no longer really
need to ship the TERMCAP variable around is the same reason that we
no longer really need termcap, or terminfo at all.  Instead just go back
to the pre-termcap way of working, and have applications speak ANSI
escape sequences directly, no need for TERM, TERMCAP or anything related
to that - any terminal emulator that can't handle that can just be corrected
to work using the standard ANSI sequences.   The only variable that's
really needed is the window size, and we have the ioctl for that one.

That is, we now have one standardised terminal type, that one we should
support, all the rest are dead.

kre

ps: for anyone that argument doesn't convince, then you should also not
be convinced by decisions to switch from termcap to terminfo - terminfo
has some advantages, but they've never been enough to drive termcap away,
as termcap simply does some stuff that terminfo cannot - the more rational
capability names in terminfo are better, its database format is better,
but "compiled" binary files??   That's insane.