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.

26 responses total.

I actually understood that! I'm glad you took the time to get to the bottom
of this Greg. It hasn't affected me, but is has been a disturbing
disruption to quite a number of users. Disruption, alas, is often
the price of progress. Only the disruption is temporary.

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.

This response has been erased.

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.

No, the rows and colums are  set to 0 in the login program. His tset
doesn't get run until his .login is sourced by his shell after it has
been exec'd by the login program. Is the order of events clear there?

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

thankxx gregc.

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

I just realized that since my problem developed, I've only logged in via
telnet.  I just logged in over a modem line, and everything worked properly.
 
Here's what's happening...  On both Grex and UMCC, I have my term set to 
VT102 and then have stty rows 42 cols 80 in the next line of my .login.
Both on UMCC and Grex (via modem), my term program works just fine.  But
when I telnet to Grex, the 42 row mode works through the You have new/no
mail message during my login.  Then the cursor jumps to the 24th row, gives
me that annoying "Erase is 'ctrl-H'" message and then does the finger
that's in my .loging, with the screen scrolling up from the 24th row.  Once
I issue a  reset terminal command to my term program.  I'm back in 42 row
mode.

What makes this even stranger to me, is I just noticed that the setenv TERM
and stty rows cols come *after* the finger in my login.

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.

Damn.  I used to do that with a vt102-42 that remmers created, but then
when things like vi on the Sun3 wouldn't recognize that, I was told to
go to vt102 and do the stty rows thing.  <sigh>  
(Oh, and the reason I have the tset $TERM is without it, I see ^H instead
of getting a back space.)

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.

Double my money back on that guarantee?

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

Grex is 152.160.30.1.  As far as I know there are no restrictions on telneting
in.  It's very convenient for getting around busy signals, but I'm telneting
in through a machine in Finland (from the only other machine from which I 
have access to unlimited telnet.  I get to it through the MSU gopher), and
somewhere along the line it's slow.

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.

Re #12: with one minor glitch, that works just fine, John.  Thanks!  The one
problem is at the end of my login sequence, my cursor jumps up to the 
second line.  What does echo '<ESC>[r' do?  (And that *is* [r after the
actual ascii escape char, right?)  I can easily live with that, though.  Now
my backspace works properly and no "Erase is ^H" message.

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.

Re #17:  The '<ESC>[r' sets the scrolling region to the full screen
on a VT-type terminal.  Echoing it to your terminal solves the problem
of having text scroll before the cursor hits the last line of the
screen.  It also homes the cursor, which explains your cursor jump
to the 2nd line.

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

Well, you could try this out on your piano:

        echo -n '<ESC>[r<ESC>[42;1H'

That would reset the scrolling region, then send the cursor to the
lower left corner of the screen.  That's a bit more tidy.

Tanks.  I'll give it a try.

Tried the remmers-fix!  Neat! Thankxx!

Thanks, John.  The last modification did the trick!

This response has been erased.

Most systems that I have been on will automagically set you up with a
"network" term type, which I think is the same as a vt52 term.  It is a
real wise idea to go into your .login and change the settings to be what
you are actually using.  

Response not possible - You must register and login before posting.

- Backtalk version 1.3.30 - Copyright 1996-2006, Jan Wolter and Steve Weiss