Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site rlgvax.UUCP
Path: utzoo!utcs!lsuc!pesnta!hplabs!hao!seismo!rlgvax!guy
From: guy@rlgvax.UUCP (Guy Harris)
Newsgroups: net.unix-wizards
Subject: Re: setting TERM on System Vr2
Message-ID: <472@rlgvax.UUCP>
Date: Wed, 13-Feb-85 10:48:00 EST
Article-I.D.: rlgvax.472
Posted: Wed Feb 13 10:48:00 1985
Date-Received: Thu, 14-Feb-85 19:03:20 EST
References: <1145@aecom.UUCP>
Distribution: net
Organization: CCI Office Systems Group, Reston, VA
Lines: 47

> Anyone know of a good method to keep TERM information for System V? 
> I know that you can type TERM=xxx when typing your login 
> name, but we have a lot of hardwired terminals, and it would be 
> more convenient to have that terminal types kept in a file and 
> have it be set automatically.  

Step 1 - rip "login" so that it doesn't destroy the environment it's
given, but adds to it.

Step 2 - make your "inittab" lines look like:

	hb::respawn:env TERM=vt100 /etc/getty ttyhb 9600	# Console VT100

which puts "TERM=vt100" into the environment of the "getty" (which, if it
wanted to, it could use); it then gets passed to the modified "login", which
in turn passes it to the user's login shell.

Alternative (this one is really addressed to the USDL) - have a "runtty"
command which gets run like

	/etc/runtty ttyhb 

which does the following:

	1) does a "setpgrp" to have the next terminal opened be the
	   control terminal (one of the least used nice USDL UNIX
	   features - you have to explicitly specify that opening
	   a terminal makes it your control terminal, so daemons
	   can be set up to safely open "/dev/console" and write
	   messages without getting attached to it.  Unfortunately
	   "init" does a "setpgrp" on all processes it spawns, which
	   ruins this utterly.  Besides, you *really* should be running
	   "syslog" and have it handle error messages...)
	2) opens its first argument as stdin, stdout, and stderr
	3) looks that up in "/etc/ttytype" (see any 4.xBSD manual for
	   a description) and puts TERM=whatever into the environment
	4) runs the command

This centralizes that code.  Right now, "getty" does that sort of thing
itself; however, if you want to run different versions of "getty" (we have
a screen-oriented "getty"/"login" which behaves like a component of our
office automation system) or something like a special data entry application
with its own operator login procedure, you can write the program like a
regular program and run it from "runtty".

	Guy Harris
	{seismo,ihnp4,allegra}!rlgvax!guy