Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84 SMI; site sun.uucp Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!genrad!decvax!decwrl!sun!guy From: guy@sun.uucp (Guy Harris) Newsgroups: net.unix Subject: Re: Setting TERM Message-ID: <2735@sun.uucp> Date: Fri, 30-Aug-85 21:01:25 EDT Article-I.D.: sun.2735 Posted: Fri Aug 30 21:01:25 1985 Date-Received: Sun, 1-Sep-85 06:02:47 EDT References: <180@ukecc.UUCP> Organization: Sun Microsystems, Inc. Lines: 37 > 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