Virtual Terminals

[BostonU SysMgr]

There's more than one definition (term is 'overloaded') but
from a 4.2 context here's a functional definition:

The UCB program 'script' works essentially by starting a shell
up to a psuedo-tty for you and going into a simple figure-8
loop taking the typein from your terminal and sending it to
the pty, taking the typeout from the pty and sending it to
your tty (copying everything into a dribble file.)

Now, say you 'lied' to the pty side and claimed to always be
a VT52 or some such no matter what was on the other end.
Now, get the termcap for the VT52 and the user's actual
terminal and just map the incoming (pty) side escape sequences
to the outgoing (your) side.

Of course, you say, why bother. Now assume your terminal just
cannot be easily described by a termcap definition but really
requires a full blown, custom program to control (maybe you
have font capability and need to do some fancy stuff to take
advantage of it so you want to translate under-scoring to italics etc,
which requires calculating new x/y position dependant on current font,
not do-able directly thru termcap.) A VTS might solve your problem.

The big split between VTS's and Termcap was that a VTS assumes
the remote tty is very hard to control and has significant
peculiarities that require a custom, smart program to control
(eg. CRTSTY on ITS). Termcap assumes that terminals are
remarkably similar and most common functions can map to a
few generic operations. Both approaches are correct under
different circumstances. Termcap is much easier to maintain,
VTS's can be much more powerful and still not force software
to 'hard code' terminal knowledge in general (maybe, but you
have to be real careful about your 'generic' terminal!)

Of course, then there are certain manufacturers who solve the
problem by filling all their code with the constants 24, 80
and 'ESC-[-H' and just tell you to buy their terminals
sigh ;-)

	-Barry Shein, Boston University