puglia@cunixf.cc.columbia.edu (Paul Puglia) (09/11/90)
Could some please tell me why stty [some mode] < /dev/tty?? doesn't work under hp-ux 7.0. I am trying to change the baud rate on the built-in RS-232 port of a hp9000s360 to test a printer and I can't seem to get the anything to change with the above stty command. I have used variations of this trick on other versions of unix (BSD and ATT derived systems) and it is always worked in the pasted. Could somebody give me a clue as to what is going on here? Thanks in Advance, Paul Puglia Dept of Civil Engineering Columbia University puglia@cunixf.cc.columbia.edu
jns@hpuerca.HP.COM (Jeff Squires) (09/12/90)
Hi there -- here is what is going on: 1) the stty(1) command does an open(2) of the device file and then does a termio(7) ioctl to set the appropriate mode -- 2) when the stty(1) command closes the device file the driver sets the modes back to the defaults (300 baud CS8 CLOCAL HUPCL) 3) this is what you are seeing when you do a stty -a < /dev/stuff after setting the port with stty(1) Here is how to fix this under HP-UX : 1) nohup sleep 999999999 < /dev/stuff & 2) stty <modes......> < /dev/stuff 3) stty -a < /dev/stuff # if you want to check that the port stays # configured the way you set it As long as the sleep(1) command has this port open then the driver will not set the port back to termio(7) defaults. When the sleep expires in 999999999 seconds or is killed then this will happen. You will probably have rebooted by then ...... Hope this helps help offered, but not guaranteed, by me or my employer ...............
maj@hpfinote.HP.COM (Mike Jassowski) (09/12/90)
> Could some please tell me why stty [some mode] < /dev/tty?? doesn't > work under hp-ux 7.0. > Paul Puglia ---------- Although I don't use 7.0, I do see similar symptoms under 6.5. It seems that the stty command works, but as soon as stty closes the device, it goes back to normal. What I do is use two windows. One opens the device for I/O, the other issues the stty command. Example: [in first window] $ cat > /dev/tty [cat opens /dev/tty and waits for input] [in second window] $ stty [some mode] < /dev/tty [stty changes device and exits] Stuff typed into the first window should now be sent/received at the requested mode. Hope this helps. -- Mike Jassowski (maj@hpesmaj.fc.hp.com, (303)229-2227) (Standard Disclaimers Apply)
wehr@fmeed1.UUCP (Bruce Wehr) (09/12/90)
In article <1990Sep11.155337.17413@cunixf.cc.columbia.edu>, puglia@cunixf.cc.columbia.edu (Paul Puglia) writes: > > Could some please tell me why stty [some mode] < /dev/tty?? doesn't > work under hp-ux 7.0. This is just a guess, but here goes. When no process has a serial line open, its stty values are undefined. When the first process opens a serial line, the values are set to defaults (300 baud, cs8, etc..). Any changes that occur will remain in effect *only* while some process has the file open. I think what's happening to you is this: when you say "stty foo </dev/ttybar", the shell forks, opens the line (the default values are put into effect), and then execs an stty. The stty then changes the values you requested. That being done, the stty process exits, the line is closed, and the changes are lost. Your fix is this: start a process that will keep the line open. Something like "nohup sleep 200000000 </dev/ttybar &". This will open the line, set the default values, and *keep the line open*. Any subsequent changes you do with an "stty foo </dev/ttybar" will remain in effect. If this looks familiar, it's because HP has this line as an option in /etc/rc, used for exactly that purpose: to set the baud rate for a serial printer, and keep it that way. I learned about this mechanism by trying to figure out why anybody would be as "stupid" as nohupping an effectively never-ending sleep in the background. Hope this helps. -- Bruce Wehr (wehr%dptc.decnet@srlvx0.srl.ford.com) (...uunet!mailrus!sharkey!fmeed1!wehr) (wehr%fmeed1.uucp@mailgw.cc.umich.edu) Ford Motor Company - Electronics Division 17000 Rotunda Drive, ETC Room LN081, Dearborn, Michigan 48121 (313)845-3039
kb@hpfcdc.HP.COM (Ken Burgess) (09/12/90)
For the stty parms to "stick" some process must be holding the port open. One common way to "hold a port" is to use the command nohup sleep 900000 < /dev/tty?? & This is done in inittab for serial line printers etc. Ken
graham@hparc0.HP.COM (Graham Eddy) (09/27/90)
> > Could some please tell me why stty [some mode] < /dev/tty?? doesn't > > work under hp-ux 7.0. works exactly as expected > This is just a guess, but here goes. When no process has a serial line > open, its stty values are undefined. When the first process opens a > serial line, the values are set to defaults (300 baud, cs8, etc..). Any i think it is more accurate to state that when the "first" open(2) occurs on a serial port, the "stty values" are set to a driver-dependent value, typically picked up from the interface board. no -default- settings on board? well, expect 300 baud, ... -graham "representing noone's view but his own"
perry@hpfcdc.HP.COM (Perry Scott) (10/10/90)
>i think it is more accurate to state that when the "first" open(2) occurs >on a serial port, the "stty values" are set to a driver-dependent value, >typically picked up from the interface board. no -default- settings on >board? well, expect 300 baud, ... > >-graham "representing noone's view but his own" The 300 ignores any port configuration switches. The port, when first opened, takes on the default values, as documented in TERMIO(7). Perry Scott