jdelsign@bfly-vax.bbn.com (John DelSignore) (12/12/88)
The problem is that tty's have two "built-in" parameters: rows and
columns, that take precedence over the number of rows and columns in the
termcap entry. Typically, a user running a window system causes these
parameters to get set to something large. When the user exits and the tty
gets closed, the rows and columns are not cleared (bug in the tty driver).
So, when the next user opens that same tty, regardless of the termcap
entry for terminal he's using, the rows and columns are set for the
previous user.
Here is a work around:
After the VT100 user logs in, type "stty everything". This will
display the rows and columns:
oak>stty everything
new tty, speed 9600 baud, 64 rows, 85 columns
...
At this point, you can set the rows and columns to 0, and the termcap
entry will be honored.
oak>stty rows 0 columns 0
oak>stty everything
new tty, speed 9600 baud, 0 rows, 0 columns
...
--OR--
oak>stty rows 24 columns 80
...
Cheers, John D.markh@cs.utexas.edu (Mark Hebets) (12/12/88)
zeke@sunfun.eta.com (Robert K. Scott) writes: > We have a curious problem with TELNET access to a SUN 3/280 running Sun/OS > 3.2. [Stuff deleted] > The problem for these users is > strange: sometimes their session thinks that they have more than 24 lines > per screen, almost as if it thinks that they have a large Suntools window. We see similar problems with both dialup and Telnet users once in a while. I usually tell them to try two things: First, if they're running Sun's Telnet from PC-NFS, delete the file EM.SES from the NFS directory. The file saves some terminal setup info from session to session, and it may do more harm than good if the last session had problems. Second, put the following code in the user's .login file. It checks to see whether the login session inherited some terminal settings and clears them. # This code is from the Sun Software Technical Bulletin issue 1987-8 # It checks to see if a previous process left "rows" and "columns" set, # and clears them. if( $TERM != "sun" ) then stty everything |& fgrep -s columns @ setscreensize != $status if($setscreensize) stty rows 0 columns 0 endif -- Mark Hebets, Software Applications Department, Radian Corp. PO 201088, Austin, TX 78720 (512)-454-4797 sun!texsun!radian!markh cs.utexas.edu!natinst/
elh@vu-vlsi.villanova.edu (Edward L. Hepler) (12/13/88)
zeke@sunfun.eta.com (Robert K. Scott) writes: > We have a curious problem with TELNET access to a SUN 3/280 running Sun/OS > ... The problem for these users is > strange: sometimes their session thinks that they have more than 24 lines > per screen, almost as if it thinks that they have a large Suntools window. > ... I found this same problem. I first attributed it to the Sun DNI product since our users were trying to "set host" from some Vaxes here. After a couple of experiments, I found that I could also get this problem to occur between Suns by using telnet and a "smaller than default sunwindow" from the "calling" machine. Rlogin works because it seems to pass window size information with the login request. I submitted this as a bug to Sun (Service Order #215803) a couple of months ago and have yet to get a reasonable response from them. I had a lot of trouble even getting them to try the experiment I told them about to convince them that the problem existed. (They simply thought that I had set the TERM env. var. wrong, etc.) My E-mail report to them (as they requested) is attached at the end of this message. I ended up finding a temporary solution.... It seems that the default term setting when logging into a Sun is a sunwindow. Once that has been set, doing setenv's set's and tset's, etc.. don't seem to phase it.. We now default to setting the term type to vt100 in the .login file. It seems that when this is done, you can later change to sun, if desired, without problem. A typical .login looks like: set path=(. ---YOUR PATH INFO---) if("`tty`" == "/dev/console")then echo -n "Suntools? " set a = $< if($a == "y")then exec /usr/bin/suntools -8bit_color_only -toggle_enable endif set term=vt100 setenv TERM vt100 tset endif I also have users run a script after logging in which (I guess I'm paranoid) reinforces all of this. It is alias'd as follows: alias vt100 source /usr/local/lib/vt100_setup where vt100_setup looks like: set term=vt100 set noglob set t=(`tset -S vt100`) setenv TERM $t[1] setenv TERMCAP "$t[2]" unset t unset noglob alias vi vi -w24 I hope this helps. Ed Hepler GE, Valley Forge, Pa. elh@vu-vlsi or ...vu-vlsi!mercury!elh Bug report Email to Sun (to pravin@sun.com)... RE: Service Order #215803 Machine type: Sun 4/110 Operating System: Sun OS 4.0 Other: DNI 6.0, TE100 6.0 Problem #1: Symptom: It is not possible to edit using vi when logged in via set host from a VAX running VMS with a vt100 terminal. Summary: When logging in from another system, it is not possible to get the remote system to recognize that the terminal is not a Sun window. Detailed Description: Example 1: (Actual working arrangement.) Log in, using a VT100, from a VAX running VMS to a Sun by doing a "set host" command. Observe that the environment variable TERM is set to "sun". Do a "setenv TERM vt100" and "tset" and observe via printenv that TERM has indeed been set. Now perform a "more" of a file or edit a file using "vi". Observe that more than 24 lines (the size of a vt100) are displayed, and if "vi" was invoked, it is not possible to edit the file. Example 2: (To isolate to only Sun environment.) Open a vt100 window on the Sun using te100tool. From that window log into another Sun using "telnet". Set the TERM environment variable on the remote Sun to vt100 as in example 1. Perform a "more" of a file or edit a file with "vi". Observe that more than 24 lines are displayed as above. Note that if Example 2 is run with "rlogin" instead of "telnet", everything works OK. It seems that rlogin passes the window parameters to the remote machine... Problem #2: Symptom: When using "dnilogin" to log into a remote VAX running VMS, terminal characteristic information is not passed properly to the VAX. Summary: The dni software doesn't seem to pass the escape seqences with terminal type and terminal parameter information back to a VAX. Detailed Description: Open a te100tool window on a Sun. From that window, do a dnilogin to a VAX running VMS. (Our systems query the terminal for its type during the login sequence. If the terminal does not respond correctly, the system prints a "Terminal type?:" query to the user.) Respond with "vt100". Once logged in, try doing a "sho term". This should cause the VAX to do a parameter query to the terminal (te100tool). The correct parameters are not shown (In fact the terminal type is shown as unknown). This now causes one to suspect either the te100tool as not responding correctly to the inquiries or the dni software as not passing the responses back correctly. To isolate the two, I did the following: I repeated the above example, but substituted the dnilogin to the VAX with a login to the VAX using kermit over an RS232 line. This time the te100tool responded correctly and the VAX did not have to prompt the user. The "sho term" command also worked correctly. Problem #3: (I have previously reported this to our local Sun office but did not mention it to you on the phone...) Symptom: The dni software generates large 'trace looking' files in the /tmp directory. Summary: Any set host from a remote VAX, and possibly copies from a remote VAX, produce what looks to be some sort of debugging trace file in the /tmp directory of the Sun which is the target of the command. Detailed Description: As noted above, files named ctermsrv.XXX where XXX appears to be a PID appear in the /tmp directory of a Sun which has been logged into via a set host from a VAX. It also appears that the files might appear when a copy to the Sun from a remote machine is performed.The files are not automatically removed, and in one case became as large as 4 Mbytes in one day. This quickly fills the root file system..... Thanks, Dr. Edward L. Hepler GE Aerospace Systems Division (215)-354-1775 elh@vu-vlsi <-- This is preferred, as I can send or receive from here. -or- elh@scovcb.ge.com <--I can only receive mail here.
jimc@math.ucla.edu (12/20/88)
zeke@sunfun.eta.com (Robert K. Scott) writes: >Access for VT100 or H19 style terminal emulation on PCs is through a >...TELNET session on the SUN. The problem for these users is >strange: sometimes their session thinks that they have more than 24 lines >per screen... That's not a bug, that's a feature! Suppose a workstation user starts suntools, and it uses a pseudo-tty for a shelltool (size 34x80). Or he does rlogin to a server from the shellltool or the big screen, getting a ptty on the server. He starts a background job with that ptty as its official tty. He exits. Some poor student attaches via CS-1/Telnet and gets the same ptty. It's still set the way the last guy left it, because his background job is still "using" the ptty. The workaround is to do if ("$TERM" == "network") stty rows 0 columns 0 9600 in each user's .login (or in the system default login script which you set up after suffering through enough of this kind of stuff; tell all the users to source it in their own .login on pain of ...) It assumes that on a Telnet from the CS-1 or otherwise when the incoming terminal type is unknown, telnetd gives you a terminal type of "network" -- some people hack their telnetd for other values. It's important not to do this when a real terminal type is known, as from rlogin or from a smart user-telnet, as the user may be doing rlogin from a Suntools window and you do want the originating window size to propagate. The "9600" catches a similar screwup from dial lines; pttys end up at 300 or 1200 baud and vi only uses part of the screen. Note that there is a bug in stty such that if you do just "rows" it trashes the "columns" setting, so you have to do both. [[ But doesn't that ruin the settings if you really do log in from a (non-standard sized) Sun window? --wnl ]] James F. Carter (213) 825-2897 UCLA-Mathnet; 6608B MSA; 405 Hilgard Ave.; Los Angeles, CA 90024-1555 UUCP:...!{rutgers,ucbvax,sdcrdcf,{hao!cepu}}!ucla-cs!math.ucla.edu!jimc ARPA: jimc@math.ucla.edu BITNET: jimc%math.ucla.edu@INTERBIT
rcd@fed.frb.gov (Bob Drzyzgula) (12/22/88)
This problem has vexed me for over a year, and I may have finally found one actual reason for its occurance. It goes something like this: User A rlogins from suntools to some server machine, runs some stuff, and exits without cleaning up completely. Process remains running on server with user A's pseudo-tty as controlling terminal. User B telnets to server from terminal server, gets same pseudo-tty. Unix now thinks that that old process belongs to new session. Even will dump output from command to user B's terminal. What's more **Unix thinks that the new terminal has the old session's terminal characteristics**. Finding the offending process, killing it off, logging out and back in again makes the problem go away. Up until last week, when I discovered this, I always had to reboot the machine to make the problem go away. I have seen this work twice since. Don't know if other things cause this that hence cannot be fixed in this way. Boggles the mind. -Bob Bob Drzyzgula Federal Reserve Board, Washington, DC, 20551 uucp: uunet!fed!rcd; Internet: rcd@fed.frb.gov
jipping@cs.hope.edu (Mike Jipping) (12/30/88)
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.eduado@ncifcrf.gov (Arthur David Olson) (01/07/89)
We've dropped the attached workaround into "/usr/local/bin/tset" here at elsie.
--ado
#! /bin/sh
: This shell script just gets around the bug of tset
: not redoing rows and cols if they are not zero and you,
: for example, switch from 80-column mode to 132-column mode.
stty rows 0 cols 0 >&2
exec /usr/ucb/tset ${1+"$@"}