Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!husc6!rice!sun-spots-request
From: jipping@cs.hope.edu (Mike Jipping)
Newsgroups: comp.sys.sun
Subject: Re: Dumb terminal screenlength problem
Message-ID: <8812190417.AA19463@rice.edu>
Date: 30 Dec 88 05:37:27 GMT
Sender: usenet@rice.edu
Organization: STC Technology Limited, London Road, Harlow, Essex, UK
Lines: 51
Approved: Sun-Spots@rice.edu
Original-Date: Sun, 18 Dec 88 16:01:05 EST
X-Sun-Spots-Digest: Volume 7, Issue 79, message 6 of 11

Various folks have written of terminal screen length problems using "tset"
on dumb terminals.  Most recently these have been Edward L. Hepler and
Robert K. Scott.  We have had the same problems here --> and finally got a
response from Sun on this.

The problem stems from the fact that the terminal type is CHANGING from
one type to another.  The real problem is an undocumented change in the
functionality of the "tset" command.  Here's a partial response from Sun:
==========
After a quick peek at the source for tset in release 4.0, it seems that
the confusion stems from some new code added to the tset command. The code
checks that the current stty values for rows and columns are both zero
before it will set new ones. The result is that once you have used tset to
initialize your terminal size by setting up your terminal as a sun (34 by
80), further invocations of tset will not effect the rows and columns
settings.

So, what you are running into is a new feature of tset in 4.0. What I
would suggest is that your users take advantage of some of tset's other
features.

For example, the following might be a place to start:

	set noglob; eval `tset -Q -s -m 'vt100:?vt100' \
	-m 'sun:?sun' dumb; unset noglob

I have filed a bug against the documentation stating that we need to get
this new feature documented along with the commands necessary to get the
desired functionality back. 
==========
The bug ID number is 1015531 (for those that keep track).  

#define FLAME ON

The response above was from the THIRD engineer on this problem.  The
problem took 2.5 months before a solution was generated.  And all this
engineer did was take a "quick look at the code".   The response came only
after I called and called and called PLUS talked to two supervisors.  And
I had started by using the E-Mail hotline to boot.  

People have been claiming a faster response time.  I sure as heck don't
see it.

#define FLAME OFF

[[ Don't you mean "#undef FLAME"?  --wnl ]]

      Mike Jipping
      Hope College
      Department of Computer Science
      jipping@cs.hope.edu