Setting TERM

Guy Harris guy at sun.uucp
Sat Aug 31 11:01:25 AEST 1985


> 	Does SysV have anything along the lines of Berkeley's
> /etc/ttytype database for specifing terminal types?

No.  (A few years ago I remember installing some software at AT&T Long
Lines.  Everybody used 1200 BPS dial-up lines to access their machines.
Users within AT&T - who are the people the USDL releases seem to be designed
for - may not have hardwired links so they may have never seen the need for
something like /etc/ttytype.)

> Or should we start re-inventing the wheel for SysV?

Well, if you fix a bit of brain damage in "login", the tools are already
there.  "login" reams out the environment when it's entered, and builds a
new one.  It should propagate the value of TERM from the environment on
entry into the new environment.  Then the /etc/inittab lines, instead of
having a command of "/etc/getty blahblahblah...", would have "env
TERM=mumble /etc/getty blahblahblah...".  The value would be stuck in the
environment by "env", propagated through "getty" to "login" and through
"login" to whatever your login shell is.

Unfortunately, if you don't have source, you can't fix "login".

Another alternative which may be better (both for S5 and 4.3BSD, which also
permits you to run things other than "/etc/getty" as a login program) would
be to have a program which opens a terminal for input and output as file
descriptors 0, 1, and 2, creates a new process group for itself and connects
that terminal to that process group, sets up TERM, and runs the program.
This way, neither "/etc/getty" nor any other program used to let users log
in would have to worry about opening the terminal or setting up the process
group.  There would be an "/etc/ttytype"-like file which would specify the
device name, the terminal type, and the baud rate(s), parity, etc..  This
program wouldn't handle the speed-switching of "getty", so "getty" would
also have to do its own speed handling; however, something like a
full-screen program for handling logins on hardwired CRTs could be written
to work more-or-less like a regular UNIX program.

	Guy Harris



More information about the Comp.unix mailing list