libes@cme.nist.gov (Don Libes) (03/13/90)
According to the man page (SunOS 4.0.3) ... The native SunOS stty(1) acts on the device that is the current stdout while their System V stty acts on the device that is the current stdin. In the interest of portability, which is preferable? Currently, 4.0.3 defaults to using the native stty. According to a Sun rep, the next release (4.1) will default to the System V version, although the next version (5.0) will not have any "preference" (his word, which he could not explain). It actually sounded to me like that have simply not yet decided. Will POSIX provide an answer, or perhaps, provide a stty90 which has a real interface? Don Libes libes@cme.nist.gov ...!uunet!cme-durer!libes
gwyn@smoke.BRL.MIL (Doug Gwyn) (03/13/90)
In article <3354@muffin.cme.nist.gov> libes@cme.nist.gov (Don Libes) writes: >The native SunOS stty(1) acts on the device that is the current stdout >while their System V stty acts on the device that is the current stdin. >In the interest of portability, which is preferable? The former is the 7th Ed. UNIX and 4BSD behavior. System V assumes you may want to redirect the output somewhere other than the terminal being probed. Your shell scripts could attempt "stty < /dev/tty > /dev/tty" just to make sure they see the terminal no matter where stdin and stdout point. (Don't use "stty <> /dev/tty", since most shells don't support <> properly.)
maart@cs.vu.nl (Maarten Litmaath) (03/14/90)
In article <JV.90Mar13162312@squirrel.mh.nl>, jv@mh.nl (Johan Vromans) writes: )... ) STTY_FLAGS=`stty -g < /dev/tty` ) sane() { stty ${STTY_FLAGS}; } ) )You can't do this from your BSD .login . Indeed. But if BSD's stty(1) would have had `-g', you *could* have done: STTY_FLAGS=`stty -g 2>&1 > /dev/tty` Csh: set STTY_FLAGS="`(stty -g > /dev/tty) |& cat`" (Both work on SunOS 4.0.3c.) I agree, however, that the SysV method is easier. -- 1) Will 4.5BSD have wait5()? |Maarten Litmaath @ VU Amsterdam: 2) Sleep(3) should be sleep(2) again.|maart@cs.vu.nl, uunet!mcsun!botter!maart
guy@auspex.auspex.com (Guy Harris) (03/14/90)
>Currently, 4.0.3 defaults to using the native stty. According to a >Sun rep, the next release (4.1) will default to the System V version, >although the next version (5.0) will not have any "preference" (his >word, which he could not explain). It actually sounded to me like >that have simply not yet decided. It sounds to *me* like your Sun rep is seriously confused. (If he couldn't explain his use of "preference", why was he using it? Yeesh.) As of when I left Sun, the intent was to have the BSD environment be the "default", in the sense that if the environment variable PATH isn't set, the "default" path will *not* have "/usr/5bin" before "/bin" or "/usr/bin" (BTW, in SunOS 4.x, there's no point in having "/bin" in your path at all, if you have "/usr/bin" there - "/bin" is just a symlink to "/usr/bin"). "5.0" has not necessarily been chosen as the name for Sun's System V Release 4-based release. If the rep was thinking of that release, the "stty" in "/usr/bin" or wherever will, as one would expect, have the System V behavior. I don't know if System V Release 4 from AT&T will have a "/usr/ucb/stty" that provides the BSD behavior or not; even if they don't, Sun might put one into their release. >Will POSIX provide an answer, or perhaps, provide a stty90 which has a >real interface? According to my copy of Draft 9 of 1003.2: The "stty" utility sets or reports on terminal I/O characteristics for the device that is its standard input. I don't think this is the latest draft, but I'd be surprised if they changed this in a later draft.
guy@auspex.auspex.com (Guy Harris) (03/14/90)
>The former is the 7th Ed. UNIX and 4BSD behavior. >System V assumes you may want to redirect the output somewhere other >than the terminal being probed. You can do that with the V7 and BSD one, it's just more painful - you have to redirect the standard error. The S5 behavior is a bit more natural, in that its output goes to, well, the standard output; the only reason I can see for the V7 behavior is that it makes it possible to set the modes on a tty other than one on which you're logged in without being super-user, since traditionally ttys have been publicly writable but not publicly readable. While in some environments this would be considered a feature ("Hey, Jane, I screwed up my tty settings; could you fix them for me? I'm on '/dev/tty73'."), it would be considered a problem in others ("stty erase 's' kill 't' intr 'y' >/dev/tty73"). Given that in 4.3BSD and now S5R4 ttys are *not* publicly writeable, but writeable only by a special group, to which programs like "write" are set-GID (so that you can't send things like the "transmit screen to host" escape sequence to somebody else's terminal), the V7 behavior doesn't buy you anything any more.
andyb@coat.com (Andy Behrens) (03/14/90)
In article <JV.90Mar13162312@squirrel.mh.nl> jv@mh.nl (Johan Vromans) writes: > > [On the topic of using stdin or stdout for stty(1): System V assumes you may > want to redirect the output somewhere other than the terminal being probed.] > > This seems quite logical to me, considering things like > > STTY_FLAGS=`stty -g < /dev/tty` > sane() { stty ${STTY_FLAGS}; } > > You can't do this from your BSD .login . You can certain capture the stty output in a variable. BSD stty probes stdout (not stdin), but it writes to stderr (not stdout). So you could write STTY_OUTPUT=`stty 2>&1 >/dev/tty` Of course, BSD doesn't support 'stty -g', but that's another issue. -- Live justly, love gently, walk humbly. Andy Behrens andyb@coat.com uucp: {uunet,rutgers}!dartvax!coat.com!andyb Burlington Coat, PO Box 729, Lebanon, N.H. 03766 (603) 448-5000
jv@mh.nl (Johan Vromans) (03/14/90)
[On the topic of using stdin or stdout for stty(1)] In article <12339@smoke.BRL.MIL> gwyn@smoke.BRL.MIL (Doug Gwyn) writes: > System V assumes you may want to redirect the output somewhere other > than the terminal being probed. This seems quite logical to me, considering things like STTY_FLAGS=`stty -g < /dev/tty` sane() { stty ${STTY_FLAGS}; } You can't do this from your BSD .login . Johan -- Johan Vromans jv@mh.nl via internet backbones Multihouse Automatisering bv uucp: ..!{uunet,hp4nl}!mh.nl!jv Doesburgweg 7, 2803 PL Gouda, The Netherlands phone/fax: +31 1820 62944/62500 ------------------------ "Arms are made for hugging" -------------------------
frank@rsoft.bc.ca (Frank I. Reiter) (03/14/90)
In article <3354@muffin.cme.nist.gov> libes@cme.nist.gov (Don Libes) writes: >According to the man page (SunOS 4.0.3) ... >The native SunOS stty(1) acts on the device that is the current stdout >while their System V stty acts on the device that is the current stdin. Why not both? stty </dev/x >/dev/x -- _____________________________________________________________________________ Frank I. Reiter UUCP: {uunet,ubc-cs}!van-bc!rsoft!frank Reiter Software Inc. frank@rsoft.bc.ca, a2@mindlink.UUCP Surrey, British Columbia BBS: Mind Link @ (604)576-1214, login as Guest
jv@mh.nl (Johan Vromans) (03/15/90)
In article <JV.90Mar13162312@squirrel.mh.nl> jv@mh.nl (Johan Vromans) writes:
`[SystemV:]
`
` STTY_FLAGS=`stty -g < /dev/tty`
` sane() { stty ${STTY_FLAGS}; }
`
`You can't do this from your BSD .login .
To which andyb@coat.com (Andy Behrens) replies:
` STTY_OUTPUT=`stty 2>&1 >/dev/tty`
`
`Of course, BSD doesn't support 'stty -g', but that's another issue.
My BSD system (Ultrix) does. But I mentioned a '.login' file for Csh.
Maarten "als iemand 't kan, is hij het wel" Lithmaat replies:
`Indeed. But if BSD's stty(1) would have had `-g', you *could* have done:
`
` set STTY_FLAGS="`(stty -g > /dev/tty) |& cat`"
Now this works.
Johan
--
Johan Vromans jv@mh.nl via internet backbones
Multihouse Automatisering bv uucp: ..!{uunet,hp4nl}!mh.nl!jv
Doesburgweg 7, 2803 PL Gouda, The Netherlands phone/fax: +31 1820 62944/62500
------------------------ "Arms are made for hugging" -------------------------