Login (unique) problems with terminal emulations.

[Brian Bartholomew]

In article <1471 at lakesys.lakesys.com> johnb at lakesys.lakesys.com
(John C. Burant) writes:

...[deleted]...

>I'm using a SCO UNIX/386, csh (heck, it doesn't work with ksh either), and
>am having trouble setting up my terminal emulation correctly.  Everything
>here has been tested with ksh and csh, so please don't direct me to try the
>same with the other shell.
>
>If, when I login, I accidentally type the wrong terminal emulation to use
>(ex. mistype: vt199 instead of vt100), the system won't find it in termcap
>and will say unknown and all's good.  But if I try to set it again to
>a terminal emulation with EVERYTHING from the manual pages of tset, termcap,
>etc. (exhaustive search of them), nothing will actually get the system
>to work (i.e., can't run things that require a good emul), and even if
>I do a csh .login or a . .profile, the system won't set it correctly, even
>going trough the whole login procedeure a second time (exececuting those
>.profile or .login files).  Now, it will act as if it did set (the system
>will even SAY IT DID!), but the TERMCAP variable is blank, as well as
>the TERM variable.

...[deleted]...

>John C. Burant | johnb at lakesys.lakesys.com    
>Glendale, Wisc | johnb at lakesys.UUCP         
>(414) 228-7915 | uunet!marque!lakesys!johnb 

I have used SCO XENIX 286 and 386, versions 2.2.1 to 2.2.3 (?) daily
for a year and a half.  The whole system was vanilla SCO, and I used
csh as my login shell.  As I remember, when you logged in, tset was set
up to prompt you about the term type, if it didn't recognize what port
you were logging in from.  If you hit return on the suggested type, it
worked.  If you entered a legal type and hit return, it worked.  If you
entered an undefined type, it bombed with some inappropriate error
message (something about indexing off the end of an array), and the
type was not set.  However, whenever I wanted to change the term type
in the middle of a login session, I just changed TERM and TERMCAP
directly, thusly:

	% setenv TERMCAP ""
	% setenv TERM wy60

This always worked.  With the number of I/O bugs we found with the
system in general, I am not suprised that tset is failing on you.

As a historical note, we discovered that this machine had a working
termcap entry for a Radio Shack model 100 notebook computer, doubtless
because XENIX was originally a Microsoft port for a TRS-something
business computer.  This was good, because we were using m100's as
remote terminals and barcode-entry machines on a factory floor.  Good
luck with the XENIX.  I do BSD now.

--
"Any sufficiently advanced technology is indistinguishable from a rigged demo."
-------------------------------------------------------------------------------
Brian Bartholomew	UUCP:       ...gatech!uflorida!beach.cis.ufl.edu!bb
University of Florida	Internet:   bb at beach.cis.ufl.edu