[comp.sys.next] NextStep2.0 vt100 termcap entry

scott@mephistopheles.gac.edu (Scott Hess) (01/15/91)

Under 2.0, NeXT has chosen to follow the rest of the world and use the
latest vt100 termcap entry in their /etc/termcap file.  This entry is
fine, but it has one flaw, so far as I can see:  the termcap initialization
sequence places the terminal in a strange mode for all terminals who
are not 80x24 characters.

To fix this, there are a couple methods.  The offending sequence is
the is sequence.  What I did on my machine is to edit /etc/termcap,
copy the vt100 sequence given, and then modified the is sequence
in the copy (the first copy is the one found, so be sure to use that
one).  Right now, is=\E[1;24r is the sequence.  This sets scrolling
regions to be from lines 1 through 24 - not too good for 60 line
displays.  I changed it to is=\E[r.  This resets the terminal to
the maximum scrolling region - where the entire display is the
scrolling region.  For terminal who are 24 line, this is no problem,
because they'll just use 24 (as that's the bottom of their display.

Another method is to copy the termcap vt100 entry to a file in your
home directory (say, .termcap), and modify it there.  For Stuart,
you can then set the Termcap default (has to be set via dwrite)
to ~/.termcap, and things should work better.  Otherwise, modify
.login (for csh users) and add the line
setenv TERMCAP ~/.termcap
sh can do this too, though I know not the commands to issue.  If
you use multiple terminal types, you'll probably want to have
an if() statement to conditionally set the TERMCAP variable.

Of course, both of these solutions only help on the local system.  For
remote systems, similar magic must be performed.  That's why I would
use the ~/.termcap version if I had to work on more than one system
(our network is set up so that all of the NeXT's look like pretty
much the same system, so it's not a problem).  4.3BSD machines can
handle the NeXT termcap entry fine (with the above modification),
so that's easy enough (copy it to your remote account and modify
.cshrc), but I'm sure SYSV machines are different.

Why was this done?  Well, it's not NeXT's fault, really - it seems that
the termcap used is the termcap from 4.3Reno, or something.  But I've
gotten enough complaints (hey, it's not _my_ fault :-) that I
figured I'd answer to the world . . .

I'm open for questions . . .
--
scott hess                      scott@gac.edu
Independent NeXT Developer	GAC Undergrad
<I still speak for nobody>
"Tried anarchy, once.  Found it had too many constraints . . ."
"Buy `Sweat 'n wit '2 Live Crew'`, a new weight loss program by
Richard Simmons . . ."