ir@crosfield.co.uk (ian reid) (02/27/91)
On all the System V machines I have worked on, I'm not sure about BSD flavours,
if you wish to change the settings of a tty line using stty that tty line had
to be opened by a process for the changes to take effect.
I have come across this most recently when trying to setup COM3 on a PC running
Interactive UNIX 2.2, to send debugging output to a VT100 terminal.
No gettys or any other process are running on COM3. COM3 is /dev/tty01
So the following sequence occurs.
prompt> stty < /dev/tty01
speed 300 baud; <rest of report deleted>
prompt> stty 9600 < /dev/tty01
prompt> stty < /dev/tty01
speed 300 baud; <rest of report deleted>
prompt> sleep 1000 > /dev/tty01&
prompt> stty 9600 < /dev/tty01
prompt> stty < /dev/tty01
speed 9600 baud; <rest of report deleted>
Of course another interesting thing is stty works on the standard input for
SysV systems, but on the standard output for BSD systems.
So why does another process have to have the tty device open for the changes to
work, and why the difference described in the previous paragraph between
different stty implementations.
--
Ian Reid #include <std/disclaimer.h>
UUCP: ir@cel.uucp or ir@cel.co.uk or ...!{ukc,mcsun,uunet}!cel!ir
"Computers..proof positive that no-one yet understands how to describe any real
world situation in 0's and 1's."jim@cs.strath.ac.uk (Jim Reid) (02/27/91)
In article <8845@suns302.crosfield.co.uk> ir@crosfield.co.uk (ian reid) writes:
Of course another interesting thing is stty (for another terminal -
JR) works on the standard input for SysV systems, but on the
standard output for BSD systems.
So why does another process have to have the tty device open for
the changes to work, and why the difference described in the
previous paragraph between different stty implementations.
The difference in implementations is System V's doing. The BSD stty
command works in the same way that its predecessors like V7 worked.
When AT&T cleaned up their tty driver, they changed the behaviour of
stty. I suspect the reasoning was to allow the text output of an stty
command to be redirected to a file or down a pipe. IMHO, this is wrong
since intuitively stty `writes' an ioctl to the terminal, and it's not
good practice to write on the standard input. Of course, other people
will take the opposite view.
As for the device open interaction with stty is concerned, this is a
side effect of the tty driver. In most implementations, the device
driver explicitly assigns default tty settings when the device gets
opened, unless the tty is already open. So if the tty wasn't open, the
driver will apply these defaults when stty comes along, opens the
device and then issues a get-tty-settings ioctl. If the tty was
already open, the driver knows this fact and therefore does not apply
the default settings. Needless to say the default settings are far
from useful - typically 300 baud, raw mode with @ and # for delete
and line kill.
Jimgwyn@smoke.brl.mil (Doug Gwyn) (03/01/91)
In article <JIM.91Feb27134014@baird.cs.strath.ac.uk> jim@cs.strath.ac.uk (Jim Reid) writes: >The difference in implementations is System V's doing. The BSD stty >command works in the same way that its predecessors like V7 worked. >When AT&T cleaned up their tty driver, they changed the behaviour of >stty. I disagree with this summary of the history. I seem to recall that PWB "stty", certainly UNIX System III "stty", shared this aspect of the current "stty" behavior. >I suspect the reasoning was to allow the text output of an stty >command to be redirected to a file or down a pipe. Exactly. This is quite useful at times. >IMHO, this is wrong since intuitively stty `writes' an ioctl to the >terminal, and it's not good practice to write on the standard input. The use of TCGETA amounts to a "read", not a "write". If you change the terminal handler settings via TCSETAW, then that amounts to a "write". "stty" has both uses.