edward@ukecc.UUCP (Edward C. Bennett) (08/29/85)
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 */
whp@cbnap.UUCP (W. H. Pollock x4575 3S235) (08/30/85)
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
wcs@ho95e.UUCP (x0705) (08/31/85)
> 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? > Edward C. Bennett > UUCP: ihnp4!cbosgd!ukma!ukecc!edward It's not like it's a tough wheel to reinvent; you have a file /etc/ttys containing two columns (device name and terminal type), and a one line shell: sed -n "/`tty` /s///p" /etc/ttys ^TAB A more fun approach is to get ahold of "ttytype", a program that tries to guess what kind of terminal you have by throwing escape sequences at it until the terminal responds with something recognizable. At AT&T Bell Labs, it's provided under the "exptools" internal software distribution system; exptools programs are often sold to the public via the AT&T Toolchest, or alternatively are System-V ports of Berkeley UNIX programs. -- ## Bill Stewart, AT&T Bell Labs, Holmdel NJ 1-201-949-0705 ihnp4!ho95c!wcs
wcs@ho95e.UUCP (x0705) (08/31/85)
(oops - that was 'ttype', not 'ttytype'; 'ttytype' was the Berkeley look-it-up-in-the-table program. I never cared much for ttytype because my terminal was usually listed there as "dialup".) -- ## Bill Stewart, AT&T Bell Labs, Holmdel NJ 1-201-949-0705 ihnp4!ho95c!wcs
guy@sun.uucp (Guy Harris) (08/31/85)
> 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
guy@sun.uucp (Guy Harris) (09/02/85)
> 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
peter@graffiti.UUCP (Peter da Silva) (09/04/85)
> 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.
davy@pur-ee.UUCP (Dave Curry) (09/04/85)
The /etc/ttytype file goes away under 4.3BSD in favor of a nifty new /etc/ttys file. The format is tty25 "/etc/getty adm.9600" adm5 on secure which says tty25 should have a getty started up on it, and that the getty should be for an ADM (Lear Siegler) series terminal at 9600 baud. The TERM variable should be set to "adm5", the terminal is "on" (logins permitted), and is secure (root may log in on it). You can run any program on the terminal this way, and set anything for the TERM variable. Since rlogin(1) passes TERM through the net, this essentially makes tset, etc. unnecessary except for dialups and initialization strings. The "adm" part lets you use /etc/gettytab, which is kind of like termcap -- you can send different clear-screen sequences, etc. to different types of terminals. The best part, of course, is that the whole mess is human-readable. --Dave Curry
henry@utzoo.UUCP (Henry Spencer) (09/06/85)
> ... 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
slb@bnl44.UUCP (Sanford L. Barr @ Brookhaven National Labs. Long Island, N.Y.) (09/09/85)
> > 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? > For some silly reason they left the ttytype database out of sysV .. yet programs like tset and the such still look for it. My solution to the problem was just creating my own under ttytype format and it works fine. Tell me how it turns out, San -- Sanford L. Barr Famous designer of the Write Only Memory. -- -- ..!decvax!mcnc!philabs!sbcs!bnl44!slb ...slb@bnl44.ARPA ...slb@bnl44.UUCP Voice phone: (516) 736-4155 Address (USnail): Almagmated Tech. 39 Royalston La. S. Setauket, N.Y. 11720 ATTN: Sanford L. Barr
wcs@ho95e.UUCP (x0705) (09/10/85)
> > ... 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 I disagree with you strongly on this one, Henry: 1) Consider 1200 baud modems + the local phone company. Sure it's not high-tech, and I'll be glad to use the next generation of data transport (Universal Information Service? ISDN? Fiber-optic+tin-cans?) if the price is right, but for a lot of the world it's reality, especially for people offering public information services. 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; I commonly have different emulators in different windows *on the same terminal* because they're good at different jobs. No way my network administrator can keep up with that for 150 people; I have enough trouble getting flow control turned on or off. (Admittedly, the network SHOULD let the users manage that, but that was a local political decision, and the next set of ROMs should make it obsolete anyway.) While it's nice if the computer ALWAYS KNOWS which lines / virtual circuits / dialup ports have what model terminal on them, it's always changing, and there needs to be some convenient mechanism for keeping track of it. -- ## Bill Stewart, AT&T Bell Labs, Holmdel NJ 1-201-949-0705 ihnp4!ho95c!wcs
barmar@mit-eddie.UUCP (Barry Margolin) (09/10/85)
In article <184@graffiti.UUCP> peter@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
guy@sun.uucp (Guy Harris) (09/10/85)
> 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
henry@utzoo.UUCP (Henry Spencer) (09/11/85)
> > 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
john@moncol.UUCP (John Ruschmeyer) (09/13/85)
]From: henry@utzoo.UUCP (Henry Spencer) ]Message-ID: <5935@utzoo.UUCP> ]Organization: U of Toronto Zoology ] ]> ... 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. Oh, well! So much for the AT&T ISN that we are buying. -- Name: John Ruschmeyer US Mail: Monmouth College, W. Long Branch, NJ 07764 Phone: (201) 222-6600 x366 UUCP: ...!vax135!petsd!moncol!john ...!princeton!moncol!john ...!pesnta!moncol!john Disclaimer: Monmouth College is a mecca for diverse opinions. It is, therefore, highly unlikely that the above opinions are those of anyone but me. "Are we gonna be starcrossed lovers or just good friends?"
psc@lzwi.UUCP (Paul S. R. Chisholm) (09/16/85)
from the System V Release 1 login(1):
The environment may be expanded or modified by supplying
additional arguments to login, either at execution time or when
login requests your login name. The arguments may either take
the form xxx or xxx=yyy. Arguments without an equal sign are
placed in the environment as
Ln=xxx
where n is a number *starting* *at* *0* [emphasis mine] and is
incremented each time a new variable name is required.
Variables containing an = are placed into the environment
without modification. . . . There are two exceptions. The
variables PATH and SHELL cannot be changed. . . . Both login
and getty understand simple character quoting conventions.
Typing a backslash in front of a character quotes it and allows
the inclusion of such things as spaces and tabs.
Thus, you can get things such as:
login: psc hp
which (depending on how you write your .profile), either sets TERM,
overides a default setting of TERM to a terminal you use all the time,
or precludes .profile for prompting for and reading a terminal name.
Note that the first argument *after* the login name is assigned to
L0 (ell zero), not L1 (ell one). Also, I have vague memories of the L0
shell variable being set, but not exported.
Neither getty(1M) online (SVR2 on a Vax) nor gettydefs(4) from the same
manual as quoted above make any mention of this feature. Maybe they
mean that in /etc/inittab, you can have TERM=foo at the beginning of the
process string? (But "sh -c 'exec FOO=bar ...'" doesn't seem to work
well.)
--
-Paul S. R. Chisholm The above opinions are my own,
{pegasus,vax135}!lzwi!psc not necessarily those of any
{mtgzz,ihnp4}!lznv!psc telecommunications company.
(*sigh* ihnp4!lzwi!psc does *NOT* work!!! Use above paths.)
"Of *course* it's the murder weapon. Who would frame someone with a fake?"guy@sun.uucp (Guy Harris) (09/18/85)
> ...Thus, you can get things such as: > login: psc hp > which (depending on how you write your .profile), either sets TERM, > overides a default setting of TERM to a terminal you use all the time, > or precludes .profile for prompting for and reading a terminal name. Unfortunately, if your login shell isn't a conventional command interpreter (i.e., you get thrown directly into some application), you lose, since you don't *have* a .profile. And if your "getty" program isn't really "getty", but some screen-oriented program, you lose even bigger. > Neither getty(1M) online (SVR2 on a Vax) nor gettydefs(4) from the same > manual as quoted above make any mention of this feature. Maybe they > mean that in /etc/inittab, you can have TERM=foo at the beginning of the > process string? (But "sh -c 'exec FOO=bar ...'" doesn't seem to work > well.) No, but (assuming you've fixed "login" to propagate whatever the setting of TERM was when it was entered), "env TERM=foo getty..." (or "env TERM=foo my_office_automation_systems_login_frame" or whatever) will work just fine. (Thanks and a tip of the hat to Eric Finger for this one.) Guy Harris