Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 alpha 4/3/85; site ukecc.UUCP
Path: utzoo!watmath!clyde!cbosgd!ukma!ukecc!edward
From: edw...@ukecc.UUCP (Edward C. Bennett)
Newsgroups: net.unix
Subject: Setting TERM
Message-ID: <180@ukecc.UUCP>
Date: Wed, 28-Aug-85 20:42:40 EDT
Article-I.D.: ukecc.180
Posted: Wed Aug 28 20:42:40 1985
Date-Received: Fri, 30-Aug-85 09:47:14 EDT
Organization: Univ. of Ky. Engineering Computing Center
Lines: 13
Does SysV have anything along the lines of Berkeley's
/etc/ttytype database for specifing terminal types? Or should
we start re-inventing the wheel for SysV?
Thanks,
--
Edward C. Bennett
UUCP: ihnp4!cbosgd!ukma!ukecc!edward
/* A charter member of the Scooter bunch */
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/5/84; site cbnap.UUCP
Path: utzoo!watmath!clyde!cbosgd!cbdkc1!cbnap!whp
From: w...@cbnap.UUCP (W. H. Pollock x4575 3S235)
Newsgroups: net.unix
Subject: Re: Setting TERM
Message-ID: <56@cbnap.UUCP>
Date: Fri, 30-Aug-85 14:09:24 EDT
Article-I.D.: cbnap.56
Posted: Fri Aug 30 14:09:24 1985
Date-Received: Sat, 31-Aug-85 08:59:35 EDT
References: <180@ukecc.UUCP>
Reply-To: w...@cbnap.UUCP (W. H. Pollock x4575 3S235)
Organization: AT&T Bell Laboratories, Columbus
Lines: 10
No, Please don't re-invent this square wheel! This "feature" of BSD unix
is not a good idea for several reasons. The strongest being that in many
environments today, the terminals are connected through some sort of network
and it is not possible to know what kind of tty is connected through any
port. Using ansi standard terminals, it is possible to dynamically determine
the terminal type (we use this, albeit with mixed success since many terminals
are not ansi standard yet).
'
Just my opinion, (I know many sites without networks use this, don't flame me)
Wayne Pollock
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: g...@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
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: g...@sun.uucp (Guy Harris)
Newsgroups: net.unix
Subject: Re: Setting TERM
Message-ID: <2746@sun.uucp>
Date: Mon, 2-Sep-85 04:30:41 EDT
Article-I.D.: sun.2746
Posted: Mon Sep 2 04:30:41 1985
Date-Received: Wed, 4-Sep-85 04:49:47 EDT
References: <180@ukecc.UUCP> <56@cbnap.UUCP>
Organization: Sun Microsystems, Inc.
Lines: 28
> No, Please don't re-invent this square wheel! This "feature" of BSD unix
> is not a good idea for several reasons. The strongest being that in many
> environments today, the terminals are connected through some sort of network
> and it is not possible to know what kind of tty is connected through any
> port.
Erroneous thinking. This feature of BSD UNIX *is* a good idea because in
many environments today, the terminals are directly wired to the machine and
it is possible to know what kind of tty is connected through a particular
port. The fact that it doesn't work in other environments is hardly a
reason to get rid of it - just define all the terminals as "unknown" or
somesuch if you suffer from such an environment.
> Using ansi standard terminals, it is possible to dynamically determine
> the terminal type (we use this, albeit with mixed success since many
> terminals are not ansi standard yet).
I wasn't aware that there was an ANSI registry of responses to a "request
for terminal type" control sequence. (I'm not even sure there's an ANSI
standard "reqeust for terminal type" sequence, but I don't have X3.64 at
hand to check.)
> Just my opinion, (I know many sites without networks use this, don't
> flame me)
Think before typing and you'll be less likely to be flamed.
Guy Harris
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84 (Fortune 01.1b1); site graffiti.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!think!harvard!seismo!
ut-sally!ut-ngp!shell!graffiti!peter
From: pe...@graffiti.UUCP (Peter da Silva)
Newsgroups: net.unix
Subject: Re: Setting TERM
Message-ID: <184@graffiti.UUCP>
Date: Tue, 3-Sep-85 18:30:42 EDT
Article-I.D.: graffiti.184
Posted: Tue Sep 3 18:30:42 1985
Date-Received: Tue, 10-Sep-85 03:41:53 EDT
References: <180@ukecc.UUCP> <56@cbnap.UUCP>
Organization: The Power Elite, Houston, TX
Lines: 10
> port. Using ansi standard terminals, it is possible to dynamically determine
> the terminal type (we use this, albeit with mixed success since many terminals
> are not ansi standard yet).
I would think that if all the terminals were ANSI standard you wouldn't need
to find the terminal type, and you could throw termcap/terminfo out. Just
wondering how useful this knowledge is...
And another miniflame about people who don't want a feature that would be
useful to us (the small systems people) because it's not useful to them.
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site ncoast.UUCP
Path: utzoo!linus!decvax!cwruecmp!hal!ncoast!bsa
From: b...@ncoast.UUCP (Brandon Allbery)
Newsgroups: net.unix
Subject: Setting Term under System V
Message-ID: <843@ncoast.UUCP>
Date: Thu, 5-Sep-85 20:07:46 EDT
Article-I.D.: ncoast.843
Posted: Thu Sep 5 20:07:46 1985
Date-Received: Thu, 12-Sep-85 21:28:42 EDT
References: <180@ukecc.UUCP> <2735@sun.uucp>
Reply-To: b...@ncoast.UUCP (Brandon Allbery)
Followup-To: net.unix
Organization: North Coast Xenix, Cleveland, OH
Lines: 53
Expires:
Quoted from <2...@sun.uucp> ["Re: Setting TERM"], by g...@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!...@Case.CSNET *
\****************************************************************************/
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!henry
From: he...@utzoo.UUCP (Henry Spencer)
Newsgroups: net.unix
Subject: Re: Setting TERM
Message-ID: <5935@utzoo.UUCP>
Date: Fri, 6-Sep-85 15:02:51 EDT
Article-I.D.: utzoo.5935
Posted: Fri Sep 6 15:02:51 1985
Date-Received: Fri, 6-Sep-85 15:02:51 EDT
References: <180@ukecc.UUCP>, <56@cbnap.UUCP>
Organization: U of Toronto Zoology
Lines: 10
> ... in many
> environments today, the terminals are connected through some sort of network
> and it is not possible to know what kind of tty is connected through any
> port....
Any network (or port switch, or whatever) that isn't willing to tell you
the connectivity so you can get this information is broken. Caveat emptor.
--
Henry Spencer @ U of Toronto Zoology
{allegra,ihnp4,linus,decvax}!utzoo!henry
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site mit-eddie.UUCP
Path: utzoo!watmath!clyde!cbosgd!ihnp4!mit-eddie!barmar
From: bar...@mit-eddie.UUCP (Barry Margolin)
Newsgroups: net.unix
Subject: Re: Setting TERM
Message-ID: <5270@mit-eddie.UUCP>
Date: Tue, 10-Sep-85 02:32:30 EDT
Article-I.D.: mit-eddi.5270
Posted: Tue Sep 10 02:32:30 1985
Date-Received: Wed, 11-Sep-85 06:08:11 EDT
References: <180@ukecc.UUCP> <56@cbnap.UUCP> <184@graffiti.UUCP>
Reply-To: bar...@mit-eddie.UUCP (Barry Margolin)
Organization: MIT, Cambridge, MA
Lines: 23
In article <1...@graffiti.UUCP> pe...@graffiti.UUCP (Peter da Silva) writes:
>I would think that if all the terminals were ANSI standard you wouldn't need
>to find the terminal type, and you could throw termcap/terminfo out. Just
>wondering how useful this knowledge is...
You would think wrongly. The problem is that the ANSI standard merely
specifies that if a device implements a particular operation, than it is
invoked by a specified escape sequence. It DOESN'T specify the set of
features that must be implemented. This is of necessity, since the
standard applies to all types of terminals, video AND printing. Thus,
an ANSI standard printing terminal would not implement many commands
that an ANSI standard video terminal might.
As a concrete example, both the VT100 and VT102 terminals use ANSI
escape sequences; however, the VT100 does not implement insert/delete
line/character operations, whereas the VT102 does.
The most annoying fact, though, is that the standard provides no way for
a system to query the device to determine what features it has.
--
Barry Margolin
ARPA: barmar@MIT-Multics
UUCP: ..!genrad!mit-eddie!barmar
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: g...@sun.uucp (Guy Harris)
Newsgroups: net.unix
Subject: Re: Setting TERM
Message-ID: <2776@sun.uucp>
Date: Tue, 10-Sep-85 04:06:00 EDT
Article-I.D.: sun.2776
Posted: Tue Sep 10 04:06:00 1985
Date-Received: Wed, 11-Sep-85 20:07:56 EDT
References: <180@ukecc.UUCP> <56@cbnap.UUCP> <184@graffiti.UUCP>
Organization: Sun Microsystems, Inc.
Lines: 14
> I would think that if all the terminals were ANSI standard you wouldn't need
> to find the terminal type, and you could throw termcap/terminfo out.
Nope. I don't think the committee that did X3.64 expected all compliant
terminals to implement every single control sequence in the standard (there
are control sequences to tell a typesetter how to hyphenate, among other
things). Being X3.64 compliant merely means that what control sequences you
*do* implement are the X3.64 ones, if there is an X3.64 version of the one
you want. A very popular escape sequence on the VT100 sets up a subregion of
the screen as a scrolling region. This is not in X3.64, so other X3.64
terminals need not implement it. An X3.64 terminal need not implement, say,
the insert/delete line/character sequences, either.
Guy Harris
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!henry
From: he...@utzoo.UUCP (Henry Spencer)
Newsgroups: net.unix
Subject: Re: Setting TERM
Message-ID: <5943@utzoo.UUCP>
Date: Wed, 11-Sep-85 12:43:41 EDT
Article-I.D.: utzoo.5943
Posted: Wed Sep 11 12:43:41 1985
Date-Received: Wed, 11-Sep-85 12:43:41 EDT
References: <180@ukecc.UUCP>, <56@cbnap.UUCP> <5935@utzoo.UUCP>, <145@ho95e.UUCP>
Organization: U of Toronto Zoology
Lines: 21
> > Any network (or port switch, or whatever) that isn't willing to tell you
> > the connectivity so you can get this information is broken. Caveat emptor.
>
> I disagree with you strongly on this one, Henry:
> 1) Consider 1200 baud modems + the local phone company...
I never said there weren't a lot of broken networks in the world! For
phones, the problem is pretty much unsolvable. But that's the worst case,
not the typical one.
> 2) My desk has a couple of terminals on it, an IBM PC (sorry), a 3B2,
> and occasionally other stuff, and generally I trade out one box a
> month, not to mention periodically stealing my officemate's data
> cables. Aside from that, the PC and the DMD 5620's I use all run
> terminal emulator programs...
He who keeps changing what's on his line should expect problems. Most
people don't have quite such a dynamic situation.
--
Henry Spencer @ U of Toronto Zoology
{allegra,ihnp4,linus,decvax}!utzoo!henry
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: g...@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