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 ttyhbwhich 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