Why 4BSD 'stty' uses stdout instead of stdin

[Donn Seeley]

>From Guy Harris (guy at rlgvax.UUCP):

	The USG UNIX solution is, I think, better; the USG "stty"
	command acts on its standard *input*.

There is a reason for the curious behavior of the Berkeley 'stty', as
I'm sure Guy knows, and it's probably useful to mention it in passing.
On 4BSD (and V7?) a tty must be opened for writing in order for a
process to set the tty's modes.  This does make a certain amount of
sense; if you don't want someone to write on your tty, then you usually
don't want them to set your tty's mode either.  It was decided that it
was simpler to get and set modes on the same descriptor, hence the
output to stderr and so on.

I'm not sure how USG Unix handles this: does the tty merely have to be
writable, as opposed to being opened for writing?  Does 'stty' get
modes from stdin and set them on stdout?  Does it care how the
descriptor was obtained?  The second of these alternatives (get stdin,
set stdout) would work on 4BSD...  If there was a '-c' option for
copying modes, you could perhaps say 'stty -c < /dev/ttyz1 >
/dev/ttyz2' and copy the modes from one tty to another.  'stty -g'
sounds useful, except that the output of 'stty' is already so close to
being input to 'stty' that it's a pity (ouch) it wasn't extended a
little farther so that 'stty < /dev/ttyz1 > file; stty `cat file` >
/dev/ttyz2' could work.

More wishful thinking,

Donn Seeley    University of Utah CS Dept    donn at utah-cs.arpa
40 46' 6"N 111 50' 34"W    (801) 581-5668    decvax!utah-cs!donn