Tech Insider					     Technology and Trends


			      USENET Archives

Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/5/84; site aecom.UUCP
Path: utzoo!watmath!clyde!bonnie!akgua!mcnc!decvax!linus!philabs!aecom!naftoli
From: naft...@aecom.UUCP (Robert N. Berlinger)
Newsgroups: net.unix-wizards
Subject: setting TERM on System Vr2
Message-ID: <1145@aecom.UUCP>
Date: Tue, 12-Feb-85 12:01:47 EST
Article-I.D.: aecom.1145
Posted: Tue Feb 12 12:01:47 1985
Date-Received: Sat, 16-Feb-85 05:59:16 EST
Distribution: net
Organization: Albert Einstein Coll. of Med., NY
Lines: 8

Anyone know of a good method to keep TERM information for System V? 
I know that you can type TERM=xxx when typing your login 
name, but we have a lot of hardwired terminals, and it would be 
more convenient to have that terminal types kept in a file and 
have it be set automatically.  
-- 
Robert Berlinger
...{philabs,cucard,pegasus,ihnp4,rocky2}!aecom!naftoli

Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 11/03/84 (WLS Mods); site astrovax.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!princeton!astrovax!wls
From: w...@astrovax.UUCP (William L. Sebok)
Newsgroups: net.unix-wizards
Subject: Re: setting TERM - actually about terminal initialization
Message-ID: <554@astrovax.UUCP>
Date: Fri, 22-Feb-85 22:13:07 EST
Article-I.D.: astrovax.554
Posted: Fri Feb 22 22:13:07 1985
Date-Received: Tue, 26-Feb-85 08:04:03 EST
References: <1145@aecom.UUCP> <472@rlgvax.UUCP>
Organization: Princeton Univ. Astrophysics
Lines: 46

The fact that this subject has been brought up now gives me an excuse to get
up upon the soap box.  I am not happy with the way either BSD or USG Unix
initializes the modes of terminals.   I think that the present method of
passing a magic cookie to getty by means of /etc/ttys or /etc/inittab is
opaque and usually does not let one fully specify the initial modes of a
terminal port.  I further do not like the contortions one has to go through
to initialize and retain the modes of terminal port without a getty, such as
that of a line printer connected to a terminal port.

I'd like to submit a counterproposal.  These ideas are not original.

1)  Define a tty ioctl that saves the current tty modes in an extra place
in the kernel tty structure.  Call these saved modes the "permanent tty
modes".  Make this ioctl executable by the superuser only.

2) Define a tty ioctl that resets the current tty modes by copying the
permanent tty modes to the current tty modes.

3) Make /etc/rc set from a script permanent tty modes for all the terminal
ports it knows about.

4) A tty would reset itself on close to the permanent tty modes.

The most common getty mode could be one in which getty simply executes ioctl
#2 to reset the tty modes from the permanent modes.

This scheme would not help dialup or network lines (as much) but would greatly
benefit the lines permanently attached to certain terminals.  I believe that at
most sites that this is the great majority of terminals.  For instance, one
would finally be able to consider fine tuning the various character delays to
the terminal connected to that line.  And, as previously mentioned, one can
set a printer attached to a tty port to 1200 baud and have it stay that way
with out having to do the horrible kluge of

	sleep 10000000 >/dev/ttyXX &

to hold it open so that it doesn't reset its baud rate back to 300.

I would also not mind seeing a TERM name stored in the terminal structure.
I think that this makes more sense than storing it in the environment as
a terminal type is logically more closely related to a tty port than it
is to a process.  A process could theoritically be controlling more than
one terminal of different types.
-- 
Bill Sebok			Princeton University, Astrophysics
{allegra,akgua,burl,cbosgd,decvax,ihnp4,noao,princeton,vax135}!astrovax!wls

Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site umcp-cs.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!bellcore!decvax!genrad!
panda!talcott!harvard!seismo!umcp-cs!chris
From: ch...@umcp-cs.UUCP (Chris Torek)
Newsgroups: net.unix-wizards
Subject: Re: setting TERM [converted to 4.2BSD gripe]
Message-ID: <3572@umcp-cs.UUCP>
Date: Sun, 24-Feb-85 03:35:14 EST
Article-I.D.: umcp-cs.3572
Posted: Sun Feb 24 03:35:14 1985
Date-Received: Wed, 27-Feb-85 07:16:41 EST
References: <1145@aecom.UUCP> <472@rlgvax.UUCP> <554@astrovax.UUCP>
Organization: U of Maryland, Computer Science Dept., College Park, MD
Lines: 28

At the very least, there should be one file with this information:

	<tty> <speed> <type>

Right now this information must be extracted from three separate
files: /etc/ttys, /etc/gettytab, /etc/ttytype.  It seems to me that
the <speed> cannot (and should not) be inferred from the <type>,
so this is the proper organization for these.

What I might like to see: /etc/ttys looking like this:

	# anything here is a comment...
	# the first entry is "enablement" (this *is* /etc/ttys)
	1 tty00 autobaud dialup
	1 tty01 9600 aaa
	0 tty02 4800 weird	# the line is busted for some reason
	1 tty03 12,3 dialup	# 1200/300 only dialup

The first two fields are of use to /etc/init; the second and third
are of use to getty, and the fourth is of use to login (when setting
TERM).

Note that no changes to the kernel would be required (though init,
a pretty sensitive process, would have to be rewritten).
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 4251)
UUCP:	{seismo,allegra,brl-bmd}!umcp-cs!chris
CSNet:	chris@umcp-cs		ARPA:	chris@maryland

Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83 (MC840302); site mcvax.UUCP
Path: utzoo!utcs!lsuc!pesnta!hplabs!hao!seismo!mcvax!jim
From: j...@mcvax.UUCP (Jim McKie)
Newsgroups: net.unix-wizards
Subject: Re: setting TERM [converted to 4.2BSD gripe]
Message-ID: <484@mcvax.UUCP>
Date: Mon, 25-Feb-85 14:30:54 EST
Article-I.D.: mcvax.484
Posted: Mon Feb 25 14:30:54 1985
Date-Received: Wed, 27-Feb-85 10:33:42 EST
References: <1145@aecom.UUCP> <472@rlgvax.UUCP> <554@astrovax.UUCP> <3572@umcp-cs.UUCP>
Reply-To: j...@mcvax.UUCP (Jim McKie)
Organization: CWI, Amsterdam
Lines: 24


Here is an extract from our /etc/ttys, which shows the format for 4.3BSD.
Note that the 'state' field can be a combination of 'off', 'on' and
'secure', there are no /etc/ttytypes or /etc/securetty type files any more.

	#
	# Terminal line definitions
	#
	# line	gettytab	termcap	       state	comment
	# ----	--------	-------	       -----	-------
	console	Console		decwriter	on	# console
	tty00	default		dumb		off	# (DH/DM) Micom line out
	tty01	default		dumb		off	# (DH/DM) Micom line out
	tty02	default		dumb		off	# (DH/DM) Micom line out
	tty03	default		dumb		off	# (DH/DM) Micom line out
	tty04	Dialup-1200	dumb		on	# (DH/DM) uucp dialin
	tty05	Dialup-1200	dumb		on	# (DH/DM) uucp dialin
	tty06	Dialup-1200	dumb		on	# (DH/DM) uucp dialin
	tty07	Auto-baud	dumb		on	# (DH/DM)
	tty08	default		dumb		off	# (DH/DM) Micom line out
	.....
	.....

--jim

Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site mit-athena.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!bellcore!decvax!mit-athena!jg
From: j...@mit-athena.UUCP (Jim Gettys)
Newsgroups: net.unix-wizards
Subject: Re: setting TERM [converted to 4.2BSD gripe] (next Berkeley release)
Message-ID: <93@mit-athena.UUCP>
Date: Wed, 27-Feb-85 10:04:23 EST
Article-I.D.: mit-athe.93
Posted: Wed Feb 27 10:04:23 1985
Date-Received: Sat, 2-Mar-85 03:25:37 EST
References: <1145@aecom.UUCP> <472@rlgvax.UUCP> <554@astrovax.UUCP> 
<3572@umcp-cs.UUCP>, <484@mcvax.UUCP>
Organization: MIT Project Athena
Lines: 45


	If you are going to let the cat out of the bag, at least get it
right (up to date).  There is additional support to run any program, not
just getty, on a terminal line, and support for User process window systems,
a'la' the X window system here at MIT, or the ITC window system at CMU.
Here is an example of one of our /etc/ttys files from here at MIT, in the
new format...  In addition, opening a terminal line has been moved from init
to getty to allow use of init as a "superdaemon" to maintain other daemon
programs.  These changes have been running here at MIT for some months, and
recently went west to Berkeley.
				Jim Gettys
				MIT/Project Athena

Here is a copy of an /etyc/ttys file.

#
# name		getty		type	status		comments
#
console	"/etc/getty e"		vt125	on secure
tty00	"/etc/getty rem.9600"	h19pc	on secure
tty01	"/etc/getty rem.9600"	h19pc	on secure
tty02	"/etc/getty rem.9600"	h19pc	on secure
tty03	"/etc/getty rem.9600"	h19pc	on secure
tty04	"/etc/getty rem.9600"	h19pc	on secure
tty05	"/etc/getty rem.9600"	h19pc	on secure
tty06	"/etc/getty rem.9600"	h19pc	on secure
tty07	"/etc/getty rem.9600"	h19pc	on secure
ttyp0	none		network
ttyp1	none		network
ttyp2	none		network
ttyp3	none		network
ttyp4	none		network
ttyp5	none		network
ttyp6	none		network
ttyp7	none		network
ttyp8	none		network
ttyp9	none		network
ttypa	none		network
ttypb	none		network
ttypc	none		network
ttypd	none		network
ttype	none		network
ttypf	none		network
ttyv0	"/usr/athena/xpty -L =65x80+4+5 -b 4 :0"	
	vs100 on secure window="/usr/athena/X 0"
ttyv1	"/usr/athena/xpty -L -fn 6x10 =40x80+0+0 :1"	
	vs100s off secure window="/usr/athena/X 1"

			        About USENET

USENET (Users’ Network) was a bulletin board shared among many computer
systems around the world. USENET was a logical network, sitting on top
of several physical networks, among them UUCP, BLICN, BERKNET, X.25, and
the ARPANET. Sites on USENET included many universities, private companies
and research organizations. See USENET Archives.

		       SCO Files Lawsuit Against IBM

March 7, 2003 - The SCO Group filed legal action against IBM in the State 
Court of Utah for trade secrets misappropriation, tortious interference, 
unfair competition and breach of contract. The complaint alleges that IBM 
made concentrated efforts to improperly destroy the economic value of 
UNIX, particularly UNIX on Intel, to benefit IBM's Linux services 
business. See SCO vs IBM.

The materials and information included in this website may only be used
for purposes such as criticism, review, private study, scholarship, or
research.

Electronic mail:			       WorldWideWeb:
   tech-insider@outlook.com			  http://tech-insider.org/