kai@uicsrd.csrd.uiuc.edu (09/15/88)
There ought to be a better way to get started using UNIX.
One thing that doesn't always get through to new BSD UNIX users is how to
setup your terminal correctly. Most people just do something like "set
term=vt100" and leave it at that. When you setup the TERMCAP environment
variable using tset, programs that use that information (for example: vi, ls,
less) startup much, much quicker.
The curses and termcap routines first check for the TERMCAP environment
variable, and if it exists, use the terminal definition found in there. If
there is no TERMCAP environment variable, the file /etc/termcap is opened,
and your terminal is searched for. This can take a noticible time depending
on how your termcap file is sorted, and where your terminal definition is
located in the file. As Sequent distributes /etc/termcap, "vt100" is closer
to the bottom that it is from the top.
Anyway, here are some of the commands I place in new user's .login file:
# term alias is used to setup terminal
alias term 'stty new crt decctlq erase ^\? kill ^U intr ^C quit ^\\
rows 0 columns 0; set noglob; eval `tset -sQ \!*`; set term=$TERM'
# initialize terminal
if ("$term" == "dialup") then
term '?tvs922-w' # dialup terminal
else if ("$term" == "ethernet") then
term 'vt102' # telnet'd in, or login after rlogin
else
term # use the default
echo "term=$term"
endif
# use backspace instead of delete on PC's
if (("$term" =~ vt102*) || ("$term" =~ trs*)) stty erase ^H
NOTE: The "term" alias is supposed to be all one long line. I split it into
two lines so it wouldn't get truncated in this note.
Here's a detailed explanation of how it works. If you know all this stuff,
consider yourself lucky. Not everyone does.
The first line defines an alias called "term" to do all the dirty work. It
executes the "stty" command to set the erase, kill, interrupt, and quit
control characters (escaping the question mark and backslash which mean
special things to the shell).
The "stty" command also sets the "rows" and "columns" to 0 so that they will
be reset later in the "tset" command. These only exist on BSD 4.3 sites.
4.2'ers should delete those.
Also selected is "decctlq", which says that after a control-S is pressed to
stop the flow of output, only control-Q will cause output to flow again. The
default is that pressing any key will cause output to flow again.
The "set noglob" command is neccessary because the TERMCAP entry, when put
out by "tset", will contain characters that the shell would misinterpret
otherwise. There is no corresponding "unset noglob, because "tset" will
execute that command for us. In fact, tset also outputs a "set noglob", but
it doesn't work (this is a bug in C-shell)!.
The third command in the term alias executes "tset" inside an "eval" command.
Just in case you don't know, this will cause the C shell to execute the commands that
tset "prints" to standard output. Tset accepts a couple of arguments, with the
important one being the terminal type you want to setup. You have some choices
here. If you always use the same terminal, you can just specify your terminal type
and be done with it. If you dialup from different places, or use different terminals
at different times, you can have tset prompt you to specify the terminal you are using,
and even specify a default (this is done by putting a question mark before a terminal
type).
You can also specify no terminal type at all. This is most useful in a
couple of cases. When you use terminals hardwired to serial ports on your
computer, the administrator can define what these terminal are in
/etc/ttytype, and then you don't have to worry about it.
If you "rlogin" from another computer connected to your ethernet network, the
terminal type you were using on the remote host is passed along
automatically, so there is no reason for you to specify it again.
Interestingly, if you "rlogin" to another host, and then type "login", the
remote host forgets what kind of terminal you are connected to, and has to
consult the "/etc/ttytype" file. I believe this is because originally the
environment was setup by (rlogind), the rlogin daemon, and the second time C
shell calls login directly.
The fourth and final command in the "term" alias sets the C-shell "term"
variable to the same thing 'tset' just put into the TERM environment
variable.
The next section tests the current setting of "term", to see if I dialed up
(term = "dialup"), telnet'd in from a PC on the network (term = "ethernet" ),
or logged in from a local terminal.
Some guru's will immediately (and correctly) point out that the "-m" option of the "tset" command
is designed for this very thing. Originally we used that. For example:
eval `tset -m 'dialup:?tvs922-w' -m 'ethernet:vt102'
But I found out that on some versions of UNIX, most noticibly one from a
vendor whose machine we own (not Sequent), but I am not allowed to publicly criticize
them (because they'll call my boss and complain ... again), the "-m"
option of the "tset" command is broken. It started happening to us when we
purchased Encore Annex terminal servers, which support the rlogin protocol,
and act like little UNIX machines with nothing but 16 serial ports and an
ethernet interface. We connected modems to our first Annex so that we could
all dialup to one group of modems and use ANY machine on the network, instead
of memorizing different numbers for each group of modems connected to each
machine.
I defined the terminal type on the Annex for the modems as "dialup", which
the annex passed along correctly. On the Sequent machines, there was no
problem. Tset say the -m 'dialup:?tvs922-w' and prompted me to see if I
wanted to use that terminal type. On the other vendor, tset always gets the
terminal type from /etc/ttytype for making the comparisons in the -m
options. The terminal type passed in by the rlogin daemon is totally
ignored. Bug reports have, so far, been unsuccessful in obtaining a fix. By
the way, I really like the Annex terminal servers. They solved the problem
of connecting terminals in offices that are much further away than 50 ft.
Anyway, these commands works on ALL BSD unix systems that I've had the chance
to use. If your systems aren't broken, go ahead and use the -m option. It
sure is shorter, but it also requires you to explain to UNIX novices exactly
what to change if they want to alter their .login.
My example above is straight out of my .login file. I use a "tvs922-w"
(Televideo tvs922 in 132 column mode) at home most of the time, but also dial
up from my Tandy 200 when I'm out of town, so I prefer to have it prompt for
terminal type. Our networked PC's all emulate "vt102" terminals, and all
other cases I assume the default is correct.
Lastly, it checks to see if my terminal is a vt102 or trs something, in which
case I want to use backspace instead of delete to erase characters on the
command line. You might want to use backspace all the time, in which case
you would just change the "erase" operand of the "stty" command in the "term"
alias to "erase ^H".
If your system has digital data switches, or other such things connected, you
might want to define them in "/etc/ttytype" as "switch" and add a test here
to allow you to setup your terminal correctly.
**************************************************
Obviously, we use C shell exclusively, but Bourne shell users can benefit
from using "tset" too. Just use:
eval `tset -SQ <termtype>`
in your .profile. I guess you're stuck with the "-m" options to do your
option checking. Good Luck.
Another nice thing about this method of setting up TERM and TERMCAP
environment variables, is that the "term" alias sticks around, just in case
you typed in the wrong terminal type.
I stumbled on the tset command by accident, back in 1986, about three or four
months after beginning to use UNIX. Our company got a Sequent Balance
computer for software development, but no one here really knew much about
using BSD UNIX. This one change improved the performance of our Sequent
Balance by a factor of 2. It was quite exciting at the time. For about a
week, the two of us that primarily used that system kept saying "Hey, try
running <command>!" as we discovered out which commands used curses, because
now they ran faster.
Since then, I've had the occation to use UNIX systems at other sites, and am
quite surprised to see that about half of them (usually businesses) don't
setup the terminal correctly.
**************************************************
Lately I've been playing with SVAE, the System V Application Environment
under BSD on our Sequent Balance. It's provides System V.2 commands (well,
the important ones), and all the libraries, so you can compile programs
written for System V, and then run them under either universe (BSD or ATT).
System V uses TERMINFO instead of TERMCAP.
From what I can tell, there is no way to store the TERMINFO information in
the environment, meaning ls, vi, and other programs all have to go searching
through the /usr/lib/terminfo directory for the terminal type each time I run
a command. I know this method is faster than searching for a terminal type
through the TERMCAP file, but it is far slower than having the information
ready in the TERMCAP environment variable. Is there something I am missing?
I hope that someone benefits from this information.
Patrick J. Wolfe (pwolfe@kai.com, uunet!kailand!pwolfe)
System Manager, Kuck and Associates Inc.ok@quintus.uucp (Richard A. O'Keefe) (09/16/88)
In article <43200043@uicsrd.csrd.uiuc.edu> kai@uicsrd.csrd.uiuc.edu writes: [recommending the use of `tset` to initialise TERM and TERMCAP, so that programs will run faster.] This is _usually_ a good idea, but it is worth using the 'time' command to see whether things have improved. When I tried it here, the time to use an editor went _UP_. >From what I can tell, there is no way to store the TERMINFO information in >the environment, meaning ls, vi, and other programs all have to go searching >through the /usr/lib/terminfo directory for the terminal type each time I run >a command. ... Is there something I am missing? A little bit. There is an environment variable TERMINFO which holds the name of the directory, so if you want vt52 terminfo to come from /usr/kai/terminfo/v/vt52 you would do TERMINFO=/usr/kai/terminfo The trouble is that a terminfo description is in binary, which means it can have NUL characters, which means that putting one in the environment isn't going to work.
chris@mimsy.UUCP (Chris Torek) (09/16/88)
In article <43200043@uicsrd.csrd.uiuc.edu> kai@uicsrd.csrd.uiuc.edu writes: >The "stty" command also sets the "rows" and "columns" to 0 so that they will >be reset later in the "tset" command. These only exist on BSD 4.3 sites. >4.2'ers should delete those. Also note that if you log in from a window on (e.g.) a Sun, rows and columns may be nonzero, and, if so, should be left as they are, because they reflect the actual size of the window. `rows' and `columns' should already both be zero on any other logins, although there are bugs here in many 4.2BSD-derived systems. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
barnett@mozart.stars.flab.Fujitsu.JUNET (Bruce Barnett) (09/18/88)
Chris Torek writes: >Also note that if you log in from a window on (e.g.) a Sun, rows and >columns may be nonzero, and, if so, should be left as they are, because >they reflect the actual size of the window. Actually, there is a known problem with SunOS 3.x. You can log in with a vt100, and find out emacs, more, vi, etc. doesn't work properly. The reason is that the pseudo-terminal is confused and thinks the number of rows is 34, instead of 24. (do a 'stty everything' to see if this is the case). To fix this problem, you should put a 'stty rows 0 columns 0' in your .login file. Also, I frequently re-size my windows after login. So the size at login time is just the initial window size. I believe this bug occurs when you run a job in the background, and log out before it terminates. The characteristics of the pty aren't reset. [Reality check time. Did I just correct Chris Torek? :-] -- -- Bruce G. Barnett <barnett@ge-crd.ARPA> <barnett@steinmetz.UUCP> uunet!steinmetz!barnett
chris@mimsy.UUCP (Chris Torek) (09/18/88)
>In article <13582@mimsy.UUCP> I noted that >>if you log in from a window on (e.g.) a Sun, rows and columns may be >>nonzero, and, if so, should be left as they are, because they reflect >>the actual size of the window. In article <BARNETT.88Sep18073324@mozart.stars.flab.Fujitsu.JUNET> [my what a big domain you have :-) ] barnett@mozart.stars.flab.Fujitsu.JUNET (Bruce Barnett) writes: >Actually, there is a known problem with SunOS 3.x. You can log in with >a vt100, and find out emacs, more, vi, etc. doesn't work properly. >The reason is that the pseudo-terminal is confused and thinks the >number of rows is 34, instead of 24. (do a 'stty everything' to see if >this is the case). >I believe this bug occurs when you run a job in the background, and >log out before it terminates. The characteristics of the pty aren't >reset. Right---but this bug does not occur in 4.3BSD-tahoe (`login' resets the tty size), and of course we fixed it here on our Suns too (there are advantages to waiting for sources---disadvantages too: we are still running SunOS 3.2). I was in fact referring to logging in to a Vax or Tahoe from a Sun, rather than the other way around. >To fix this problem, you should put a 'stty rows 0 columns 0' in your >.login file. Or fix login, rlogind, and telnetd (but for that you need source). >Also, I frequently re-size my windows after login. So the size at >login time is just the initial window size. In fact, if you have the `new' rlogin protocol (which---of course!--- we installed on our Suns), you can use the simple alias alias resize 'echo -n "^[[8;\!:1;\!:2t"' which works under both X and SunView. This changes the window size on the Sun, which sends a SIGWINCH, which triggers the Sun rlogin to send the window size to the remote host, which sets the new window size. I believe SunOS 3.5 already supports the new rlogin protocol. >[Reality check time. Did I just correct Chris Torek? :-] As they say, `close, but no cigar.' :-) >Bruce G. Barnett <barnett@ge-crd.ARPA> <barnett@steinmetz.UUCP> > uunet!steinmetz!barnett (But what about all the JUNET stuff in the header?) -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
andrew@frip.gwd.tek.com (Andrew Klossner) (09/27/88)
[]
"You can log in with a vt100, and find out emacs, more,
vi, etc. doesn't work properly. The reason is that the
pseudo-terminal is confused and thinks the number of
rows is 34, instead of 24."
"Right---but this bug does not occur in 4.3BSD-tahoe (`login'
resets the tty size) ..."
So if I use the "login user" command in a window to become a different
user, my window size is lost?
We put this bugfix in init. Just before it execs getty, it resets rows
and columns to zero. (We couldn't do this in getty because getty may
be run in a window, put there by our "xstart" utility.)
-=- Andrew Klossner (decvax!tektronix!tekecs!andrew) [UUCP]
(andrew%tekecs.tek.com@relay.cs.net) [ARPA]