wls@astrovax.UUCP (William L. Sebok) (02/23/85)
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!wlsrpw3@redwood.UUCP (Rob Warnock) (02/25/85)
+--------------- | 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... | 2) Define a tty ioctl that resets the current tty modes ... | 3) Make /etc/rc set from a script permanent tty modes ... | 4) A tty would reset itself on close to the permanent tty modes. | Bill Sebok Princeton University, Astrophysics | {allegra,akgua,burl,cbosgd,decvax,ihnp4,noao,princeton,vax135}!astrovax!wls +--------------- The Fortune Systems FOR:PRO version of Unix does almost exactly that, with the difference that "savemodes" saves "the current characteristics as the defaults for the tty on subsequent first opens". Thus, item #2 is not provided (but doesn't seem to be needed), and #4 is accomplished in a slightly different way (first open rather than last close). The Fortune feature works just fine, and seems to do exactly what you want. Since "stty" sets the modes as it encounters them, one only needs to mention the "savemodes" last. I put the following two lines are in the ".rc" file on my system, as needed for my configuration: stty 1200 savemodes >/dev/tty01 # Diablo printer - make it sticky stty 1200 hupcls savemodes >/dev/cul0 # kludge for hangup problem Is this what you were suggesting? (Note: I may be biased in this matter, as I was working there when this feature was implemented. Nevertheless, I have found it useful myself.) Rob Warnock Systems Architecture Consultant UUCP: {ihnp4,ucbvax!dual}!fortune!redwood!rpw3 DDD: (415)572-2607 USPS: 510 Trinidad Lane, Foster City, CA 94404