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!ucbvax!decvax!decwrl!sun!guy
From: guy@sun.uucp (Guy Harris)
Newsgroups: net.unix
Subject: Re: Setting Term under System V
Message-ID: <2790@sun.uucp>
Date: Thu, 12-Sep-85 01:03:29 EDT
Article-I.D.: sun.2790
Posted: Thu Sep 12 01:03:29 1985
Date-Received: Sat, 14-Sep-85 05:15:07 EDT
References: <180@ukecc.UUCP> <2735@sun.uucp> <843@ncoast.UUCP>
Organization: Sun Microsystems, Inc.
Lines: 50

> | > 	Does SysV have anything along the lines of Berkeley's
> | > /etc/ttytype database for specifing terminal types?
> | 
> | 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
> 
> 	.	.	.
> 
> I have a better idea.  We're talking System V, right?  So, if you have the
> Berkeley tool ``tset'' put the following in /etc/profile (and
> /etc/cshprofile if you have csh with the correct patches...
> 
> If you don't have an /etc/profile -- Are you sure you're running System V?

Not all users who log into a System V system have /etc/profile run before
they're logged in.  Not all programs which are run under a System V system
are run after /etc/profile is run.

At CCI, we had an office automation system that had a fairly fancy
screen-oriented user interface.  This program must know what kind of
terminal it's running on Most users on a customer's machine would have this
system as their login shell.  This system had absolutely no components of
the Bourne shell in it, so it couldn't run /etc/profile.

And that's not the worst of it.  Systems III and V permit you to run some
program other than "/etc/getty" on a terminal.  I wrote a program at CCI
which substitutes for /etc/getty and /{etc,bin}/login.  It presents a screen
form to be filled in with the user name and password; said form is presented
in the same fashion as other forms in the aforementioned office automation
system.  Users used to complain that the erase/kill conventions were
different when trying to log in and when logged in and talking to the OA
system.  Use this program instead of "/etc/getty" - no problem.  The same
conventions are used in both circumstances.  Since this program is
screen-oriented in the same way the rest of the OA system is, it also needs
to know TERM - and has to know it before the user is even logged in!

You can modify *every* program that could be used as a login shell to have a
way of setting TERM, but this is incredibly wasteful.  There is no point in
having N versions of code to set TERM or to read a command script in a
language powerful enough to run "tset" and set the terminal type from its
output.  Setting TERM should be centralized.

Having the program ask the user to tell it what kind of terminal it's
running on *every* time they log in (and having them ask "why the heck can't
it remember that I've had a VT100 installed on my desk" after the 12th time
it asks the same question and is given the same answer) is another
alternative, but it's too tacky for words.

	Guy Harris