gordon@prls.UUCP (Gordon Vickers) (03/29/89)
Does anyone know why stty(1) may be behaving differantly in Ultrix 3.0 ?
I normally use something like:
stty 9600 >/dev/tty07
to change selected parameters on a given port and this method has always
worked until I installed Ultrix 3.0 .
Changing port parameters now, seems to work only on login ports.
I've retreived stty from Ultrix 2.0 but it seems ineffectual as well.
From a privelaged account, I can :
stty >/dev/tty07 # or tty{any non login port} and note the baud rate
# which I don't think is aways accurate anymore, then
stty 9600 >/dev/tty07 # to try and change the baud rate. Then:
stty >/dev/tty07 # and see that the baud rate did NOT change.
I've used baud rate only as an example, ANY other valid parameter may be
substituded.
Can someone please explain why this is happening ?
I use stty faily frequantly and in fact relie upon it so any help would
be greatly appreciated.
Thankyou,
Gordon Vickers 408/991-5370 (Sunnyvale,Ca); {mips|pyramid|philabs}!prls!gordon
------------------------------------------------------------------------------
Every extinction, whether animal, mineral, or vegetable, hastens our own demise.rusty@garnet.berkeley.edu (03/29/89)
The reason the parameters change back to what they were when you do # stty > /dev/tty07 # stty 9600 > /dev/tty07 # stty > /dev/tty07 is because inside the device driver it resets them back to the default values (wired into the device driver) when the device is closed by the last process that has it open. (Or is it that it changes them when you're opening the device if nobody else already has it open?) Since your stty is the only one that had it open, they are reset when it closes the device. The reason they stick when there is a getty/login running on that line is because the getty/login still has the line/device open. I'd be surprised if this is new behavior under 3.0; this has been the way that Unix has done it since the beginning. Thus, if you want to do something at a different speed (or otherwise) you can use parens: # ( stty 9600 ; cat file ) > /dev/tty07 The tty line is kept open during the duration of the whole command line inside the parens, and everything inside the parens has stdout directed to /dev/tty07. -- -------------------------------------- rusty c. wright rusty@violet.berkeley.edu ucbvax!violet!rusty
barnett@crdgw1.crd.ge.com (Bruce Barnett) (03/29/89)
In article <20471@prls.UUCP>, gordon@prls (Gordon Vickers) writes: > > Does anyone know why stty(1) may be behaving differantly in Ultrix 3.0 ? > I normally use something like: > stty 9600 >/dev/tty07 > to change selected parameters on a given port on BSD systems, I have always used (stty 9600;cat file) >/dev/tty07 The tty settings are reset when the process exits. I think Ultrix 3.0 fixed a bug. -- Bruce G. Barnett <barnett@crdgw1.ge.com> a.k.a. <barnett@[192.35.44.4]> uunet!steinmetz!barnett, <barnett@steinmetz.ge.com>
grr@cbmvax.UUCP (George Robbins) (03/29/89)
In article <20471@prls.UUCP> gordon@prls.UUCP (Gordon Vickers) writes: > > Does anyone know why stty(1) may be behaving differantly in Ultrix 3.0 ? > I normally use something like: > stty 9600 >/dev/tty07 > to change selected parameters on a given port and this method has always > worked until I installed Ultrix 3.0 . > Changing port parameters now, seems to work only on login ports. > I've retreived stty from Ultrix 2.0 but it seems ineffectual as well. The general notion is the stty parameters only stick as long as something has the file open. When it is closed, the parameters will be set back to the default. Could it be that when you re-installed Ultrix that the port you were accustomed to doing this on no longer has something floating about that was holding it open in your old setup? Either a login or the task that you were setting the parameters for? On the other hand, perhaps DEC has broken something... you can always try (stty xxxx; sleep 99999) > /dev/ttyx -- George Robbins - now working for, uucp: {uunet|pyramid|rutgers}!cbmvax!grr but no way officially representing arpa: cbmvax!grr@uunet.uu.net Commodore, Engineering Department fone: 215-431-9255 (only by moonlite)