bsa@ncoast.UUCP (Brandon Allbery) (09/06/85)
Expires: Quoted from <2735@sun.uucp> ["Re: Setting TERM"], by guy@sun.uucp (Guy Harris)... +--------------- | > 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 . . . | 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 . . . 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; Plexus sys[35] does): SH CSH TERM="`tset -`"; export TERM setenv TERM "`tset -`" If not, a cheap ``tset -'' can be built easily and placed in /etc/profile. It would be something like: : # # Print the terminal type from /etc/ttytype. This file has terminals # and TERM values as follows: # # ^ttytype<tab>terminal$ # # where ^ is beginning of line and $ is end of line. # grep "<tab>`tty`\$" /etc/ttytype | cut -f2 Note that the format of this /etc/ttytype is rather fixed. If you don't have an /etc/profile -- Are you sure you're running System V? Or did AT&T realize it had done something right in System III and remove it from System V? --bsa -- /****************************************************************************\ * Brandon S Allbery, 6504 Chestnut, Independence, OH 44131 +01 216 524 1416 * * (phone and address subject to change in ca. 1-2 months when I get an apt.) * * 74106,1032 CIS BALLBERY MCIMAIL TELEX 6501617070 ncoast!bsa@Case.CSNET * \****************************************************************************/
guy@sun.uucp (Guy Harris) (09/12/85)
> | > 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