There are various incarnations and extensions of ANSI terminal emulation.
What most people think of as "ANSI" is the very simple subset of ANSI
X3.64 implemented on IBM PCs in ANSI.SYS. This is the basis of most
BBS's, and is implemented in most popular PC communication programs.
Then there are the highly evolved variations found on SCO, Linux,
Interactive, and UnixWare consoles. As I understand it, SCO and Linux use
a common definition ("SCOANSI"), whereas Interactive and UnixWare use
another ("AT386"), and the two are incompatible.
We (the Kermit Project at Columbia University) produce a terminal
emulator, Kermit 95, that supports all three: Basic (BBS) ANSI, SCOANSI,
and AT386 (and another variant called Avatar/0+ used by some BBSs).
Now in addition, recent releases of Kermit 95 also support Telnet terminal
type negotiation, in which the client announces its terminal type, and if
the server does not recognize the name, it can say "no, please switch to
another terminal type and send me its name"; the process repeats until a
name is found that both sides agree upon, or the client's list is
Here's the problem: Kermit 95 clients coming into SCO systems quite
naturally set their terminal type to SCOANSI. But the name SCOANSI is not
known to any SCO system (Xenix, UNIX, ODT, OSR5). So then Kermit 95 drops
down to "plain old" ANSI and SCO agrees. BUT... The SCO terminal type
called ANSI is what Kermit 95 (and Linux) call SCOANSI, and so the two
types do not agree, and screens become fractured, function keys don't
work, and so on.
Currently, we tell users to (a) command Kermit 95 to fib about the name
of its terminal emulation (set it to SCOANSI but tell the host it is
ANSI), or (b) install a terminal type on the SCO end that is called
SCOANSI, which is just a copy of its ANSI type.
Now, given that we need to support SCOANSI on Linux, where it is *called*
SCOANSI, as well as "plain old" ANSI (which is called by that name on most
OS that have named terminal types), in addition to SCOANSI on SCO (where
it is called ANSI), is there a better solution to this problem?
I'd be especially interested in commentary from SCO. Wouldn't it make
sense for SCO to distribute terminfo/termcap entries named "scoansi"?
Otherwise, the term "ANSI" becomes awfully overloaded...
By the way, I notice that the same thing happens when I set my terminal
type to AT386 and log in to (now SCO) UnixWare 2.1.1 -- UnixWare does not
recognize the name "at386", but it does recognize ANSI -- which, I assume,
is its name for AT386. So already we have three different and
incompatible terminal types with the same name.