Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!zaphod.mps.ohio-state.edu!wuarchive!uunet!auspex!guy
From: guy@auspex.auspex.com (Guy Harris)
Newsgroups: comp.unix.wizards
Subject: Re: how to check port settings on a Sun
Keywords: stty; /dev/ttya;
Message-ID: <8084@auspex.auspex.com>
Date: 29 May 91 17:55:14 GMT
References: <837@hartmanis.albany.edu> <1991May23.191124.359@st-andy.uucp> <1991May29.072411.10954@thunder.mcrcim.mcgill.edu>
Distribution: usa
Organization: Auspex Systems, Santa Clara
Lines: 78

(Hmm.  Distribution: usa, but you got a copy.  Did we annex you and just
not tell anybody?  Or did you annex us?  :-))

>> The BSD stty (which you will run by default - it's in /bin) will not
>> change or check the settings of anything other then the tty you are
>> executing it from.
>
>Then it's not a real BSD stty;

Well, if it's SunOS 4.x, no, it's not a real BSD "stty"; it's a System V
Release 3.1 "stty" with some changes:

	1) #ifdeffed code so that it can be compiled to use its file
	   descriptors BSD-fashion (set/get mode of stdout, print modes
	   on stderr) or S5-fashion (set/get mode of stdin, print modes
	   on stdout), the former being "/usr/bin/stty" and the latter
	   being "/usr/5bin/stty";

	2) added special characters and mode bits for the BSDish
	   additions (which came from a proposal to POSIX; Sun didn't
	   invent them, and they're also showing up in 4.3-reno, System
	   V Release 4, AIX 3.1, and probably others hopefully including
	   OSF/1);

	3) added some additional aliases and combined modes to support
	   BSDish settings (e.g., "cbreak" == "-icanon");

	4) added support for "stty size" and "stty speed".


> Sun must have broken it.

No, the poster is just confused; perhaps they didn't know what file
descriptor it acts on, 'cuz "/usr/bin/stty" can have its standard output
redirected to another terminal to change its modes (if you have
permission to do so).

> Real Berkeley stty ("@(#)stty.c      5.4 (Berkeley) 4/4/86") does most
> of its ioctls to file descriptor 1, meaning it will print/change the
> settings of its stdout.  (Exceptions: "stty size" and "stty speed"
> explicitly use /dev/tty for some inscrutiable reason.)

Well, actually, that's one thing that *was* broken in SunOS 4.0,
although 4.1 fixes it.

The standard "print a mode" and "set the modes" stuff acts on file
descriptor 1 because the V7 "stty" worked that way; it may have worked
that way because, in older UNIXes (V7, BSD before 4.3BSD, System V
before SVR4) user's terminals were publicly writable, but not publicly
readable, and they may have wanted to let people repair the settings on
other people's terminals without becoming super-user; you couldn't
redirect the input of "stty" to somebody else's terminal, but you could
redirect its output.  (If somebody such as DMR is listening, could they
confirm or deny this hypothesis?)

Unfortunately:

1) that also lets you *damage* the settings on other people's terminals,
   if they haven't done "mesg n" to deny write permission;

2) it doesn't help on systems that don't make terminals publicly
   writable, e.g. 4.3BSD and later, and systems that have picked up the
   4.3BSD notion, including, I think, System V Release 4;

3) it makes it a pain to send the output of "stty" elsewhere, since it
   goes to the standard *error*, not the standard *output*, as the
   standard output may be going to another terminal.

I think the output of "stty size" and "stty speed" is often captured and
redirected, e.g. `stty speed`; Berkeley presumably made it act on
"/dev/tty" so that it would work if its standard output were redirected
to, say, a pipe, as in `stty speed`.  SunOS 4.0[.x] still acts on the
standard output in that case, which doesn't work, but 4.1 fixes that.

S5 acts on its standard input, so that's not a problem there; its output
can be redirected elsewhere, and it even has a flag to dump its settings
in an encoded form that can also be used to restore the settings.  I
suspect that stuff may be in POSIX 1003.2, so BSD may pick it up.