Info on fix(I hope) to the tty rows problem.

Feb 14 21:59 UTC 1994

Here's some technical information on the changing rows and columns problem
on Grex. It's kinda technical, so you might want to skip this item, if
you're not interested.

SunOS 4.1.1 more or less conforms to POSIX and uses the newer TERMIO/TERMIOS
structures to store terminal information. However, sun also has an
apparently non-standard extension in the kernal and stores a "winsize"
struct for each terminal. The structure looks like this:

struct winsize {
        unsigned short ws_row;
        unsigned short ws_col;
        unsigned short ws_xpixel;
        unsigned short ws_ypixel;
        } ;

According to the manual, the ws_xpixel and ws_ypixel are not used by anything
at this time. Also the kernal *stores* the values of ws_row and ws_col so
they are a common, known, point of reference, but the kernal itself doesn't
actually do anything with these values.

However, user programs that are aware of the availibility of these values
can use them. All of the programs that come with SunOS and, I suspect, many
of the gnu utilities, know about these values. That's why stty displays
a "rows" and "cols" value on this system, but not on a System V box.

I know Vi understands these values and I suspect some of the other editors
on the system do to. I suspect that Vi looks at them and says "Does the
kernal have sane values for rows and cols?", if not, it uses the values
from the user's termcap/terminfo. For example, if rows and cols are both
0, then vi gets the values elsewhere.

The tset command *does* set these values from the user's termcap, *however*
there is nothing in the getty/login code to reset the back to 0. Myself,
and I suspect a fair number of users, don't use tset. So I suspect the
following sequence is happening:
1.) User with non-standard terminal size logs in and runs tset, this
    sets rows and cols for that tty.
2.) Next user logs in with standard size terminal, but isn't using tset.
3.) He runs vi and vi sees that rows and cols have valid values and uses
    those and ignores termcap/info.

I have put code into the login program to set rows and cols both back to
0 on each login, this should solve the problem regardless of whether a
user uses tset or not.

I suspect that the original SunOS login program knew about and cleared
rows and cols on each login, but the Shadow login program, because it was
meant to be a more generic program that could be built on many systems,
did not.

I actually could have put this fix in a couple of weeks ago, but I wanted
to better understand the problem before I just started applying random
bandages.

response 2 of 26:

Feb 15 01:58 UTC 1994

So I suppose if the users aren't dead or something as a result, it's okay.

I think we did the right thing by jumping onto the Sun-3 and then fixing
the resulting messes as they arose.  If we'd had to find and fix all these
problems beforehand, we'd still be on the Sun-2 in 1995.

Every program I've tried on the Sun-3 that cares about screen size does
seem to use the kernel row and column values if they're sensible and default
to the termcap-specified values otherwise.  This includes all the editors,
"more", "less", and "nethack".  I suspect that's because they all use
standard termcap library  functions to get the screen size, and the 
termcap library does it that way.

response 4 of 26:

Feb 16 00:16 UTC 1994

Morel complained in the system problems item in agora about a new problem.
It sure sounds to me like it might be a reaction to this "fix".
Perhaps it is because the rows and columns are being reset in thelogin
program too late, and are wiping out morel's settings? - A wild guess.

response 6 of 26:

Feb 16 07:27 UTC 1994

Yup. I was sort of grasping at straws. Morel's problem must be unrelated.

response 8 of 26:

Feb 16 18:44 UTC 1994

I just found this item.  Let me check something out, and then I'll report
back here about what I've been running into.

response 10 of 26:

Feb 16 20:21 UTC 1994

Mike, you have a "tset $TERM" in your .cshrc. Your .cshrc files gets sourced
first on login and then your .login gets sourced. I'm not sure what your
$TERM is set to, I suspect it is "dialup", at that point you rows are set
to 24 and your cols are set to 80. Later, in your .login, the stty commands
put them back. However, you are using a standard dec terminal emulation,
vt102, and a non-standard row setting for that terminal. It might make
more sense to build yourself a custom vt102-42 termcap entry, place it
in your home directory as the file "mytermcap" and set the TERMCAP
environment variable to it with "setenv TERMCAP /home/morel/mytermcap.

response 12 of 26:

Feb 17 02:13 UTC 1994

I think Greg's right that that "tset $TERM" is being executed
too early (and possibly too often as well, because .cshrc is
executed every time you spawn a subshell).  But there shouldn't
be a need to create a custom termcap.  I recommend

(1) take the "tset $TERM" out of your .cshrc

(2) take everything that has to do with terminal definition and
settings out of your .login and put in the following:

        set term=vt102
        unsetenv TERMCAP
        eval `tset -sQ`
        stty rows 42 cols 80 erase '^H'
        echo '<ESC>[r'

where the <ESC> should be an actual ascii escape character
(control-[).  Note also the *backward* quotes in the eval
command.

If you do all this, I guarantee you eternal contentment and
satisfaction.

response 14 of 26:

Feb 17 04:46 UTC 1994

Michael wants to know, what is Grex's IP address? What are the current restric
tions on telnetting in (for nonmembers)? Thanks.

response 16 of 26:

Feb 17 05:45 UTC 1994

You can also do "telnet cyberspace.org", you shouldn't need the IP address.
Finland?! Gee, I can't imagine why it's so slow.
Here's the scary part: I just did a traceroute to that site in finland that
scg was talking about, it takes 19 hops for the message to get from here
to there, with an average round-trip time of 500ms, it takes 18 hops for
a message to get from Grex to my machine at work in Troy, MI., with an
average RTT of 700ms. Sheesh, maybe I should move to Finland.

response 18 of 26:

Feb 17 20:14 UTC 1994

re 16:
        Except that I wasn't in Finland.  I was in Ann Arbor.  I got to the
freenet in Finland through MSU gopher.  The real slowdown seems to come 
somewhere between MSU and Finland.

response 20 of 26:

Feb 18 04:25 UTC 1994

(So there's no way to keep it from homing the cursor?  I know, picky,
picky, picky...)

response 22 of 26:

Feb 18 15:40 UTC 1994

Tanks.  I'll give it a try.

response 24 of 26:

Feb 18 23:59 UTC 1994

Thanks, John.  The last modification did the trick!