Very Computer

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
exhausted.

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.

- Frank

: It'd be quite simple to make an addendum to your docs for the sysadm to
: copy terminfo/a/ansi to terminfo/s/scoansi and add the proper lines to
: whatever termcap files.  
:
We have done this.  But users often don't read docs -- they notice
problems and become confused and/or disgruntled.

: BTW, Kermit95 isnt the only app dealing with this omission.  SCO and
: LINUX _should_ do this.
:
Linux is OK -- they call SCOANSI "scoansi".  (But then, they call ANSI
"pcansi", and I'm not even sure what that is -- if you set your terminal type
in Linux to pcansi and try to run EMACS, EMACS says that this terminal type
is "not powerful enough to run Emacs; it lacks the ability to position the
cursor...")

I guess I'm suggesting that it might be worth SCO addressing the problem
(which is indeed trivial) in a way that makes *all* SCOANSI-emulating (and
AT386-emulating) applications work nicely with SCO platforms by including
terminfo/termcap entries with the "scoansi" and "at386" names, and perhaps
also issuing patches for this for current SCO UNIX/ODT/OSR5 installations.

- Frank

[snip]

: 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.

at386 is recognized on my UnixWare 2.1.1

infocmp at386 | head -3
#       Reconstructed via infocmp from file: /usr/share/lib/terminfo/a/at386

        am, bw, eo, xon,

: - Frank
--
--
Tim Rice        Multitalents            707 887-1469

{ 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
{ exhausted.

{ 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.

It'd be quite simple to make an addendum to your docs for the sysadm to
copy terminfo/a/ansi to terminfo/s/scoansi and add the proper lines to
whatever termcap files.  

BTW, Kermit95 isnt the only app dealing with this omission.  SCO and
LINUX _should_ do this.

--

---------------------------------------------------------------------------
                  How you look depends on where you go.
---------------------------------------------------------------------------
Gary L. Burnore                       |  Y?3oY3T3oY3Y?3oY3T3oY3Y3T3oY3YY?3
DataBasix                             |  Y?3oY3T3oY3Y?3oY3T3oY3Y3T3oY3YY?3
San Francisco, CA                     |  Y?3oY3T3oY3Y?3oY3T3oY3Y3T3oY3YY?3
                                      |  Y?3 3 4 1 4 2  Y3T3 6 9 0 6 9 Y?3
http://www.databasix.com              |     Official Proof of Purchase
===========================================================================

Quote:> > I guess I'm suggesting that it might be worth SCO addressing the problem
> > (which is indeed trivial) in a way that makes *all* SCOANSI-emulating (and
> > AT386-emulating) applications work nicely with SCO platforms by including
> > terminfo/termcap entries with the "scoansi" and "at386" names, and perhaps
> > also issuing patches for this for current SCO UNIX/ODT/OSR5 installations.

> I've submitted a request to have "scoansi" added as a synonym for "ansi"
> in the next OpenServer release.

Quote:> I don't see that a SCO-provided patch for current releases would solve
> the problem any better than your instructions to the user.

Thanks very much for your help!

- Frank

Frank da Cruz's CPU sent forth this bytestream:
|
| > I don't see that a SCO-provided patch for current releases would solve
| > the problem any better than your instructions to the user.
| >
| I'm not familiar with SCO patching procedures, but if they are like some other
| vendors that issue "jumbo" patches from time to time, and this was among them,
| people might install it before they even knew there was a problem. No big
| deal.

SCO makes patches that fix many things, but they're still going to be in
some particular area, like tcp/ip, filesystem driver, keyboard, video...

But whatever the patches that SCO issues for any set of problems: first,
people have to know a patch exists; second they have to know they need it;
third they have to get it; fourth they have to read the instructions; fifth
they have to install it...

There's many a slip twixt cup and lip...

--

Quote:

>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
>exhausted.

Note that the xterm type is different that either at386 or scoansi, but seems
to be more generally available.  Also note that most BBS's understand the
xterm type.

I would default kermit to the xterm type for telnet sessions, unless another
type is negotiated at connect time.

--
"It was the year of hope.  It was the year of pain.       | Scott G. Hall
 It was the year of great joy."  (Babylon-5 opener)       | Lucent Technologies
----------------------------------------------------------| Bell Labs - BCS

BTW, I just started using porting my software to UNIXWARE and may not
know the best TERM setting (TERM=at386). Any info would be appreciated.
--
Peter vR. Cooper

64 Honda 90, 67 Hodaka 100, 69 CZ 250
80 Seca 750, 94 Magna 750, 88 VMAX, 97 Thunderace

c/o E.D.  'Your First Amendment rights are in danger because
              your Second Amendment rights are in danger.'