Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!cs.utexas.edu!rice!sun-spots-request From: chron!magic706!sysnmc@uunet.uu.net (Matt Cohen x7023) Newsgroups: comp.sys.sun Subject: Re: stty problem Keywords: Miscellaneous Message-ID: <3810@brazos.Rice.edu> Date: 2 Dec 89 23:32:44 GMT Sender: root@rice.edu Organization: Sun-Spots Lines: 36 Approved: Sun-Spots@rice.edu X-Refs: Original: v8n192, Replies: v8n198 v8n207 X-Sun-Spots-Digest: Volume 8, Issue 218, message 7 of 15 "It's not a bug, it's a feature." In sun-spots v8n207, ghfeil@white.toronto.edu (Georg Feil) says: >Using 'stty -parenb cs8 >/dev/ttyb' gives no errors >but also has no effect.... >I tried changing the std.9600 entry for ttyb in >/etc/ttytab to something else, but this has no effect if the device is >'off'... >I finally resorted to writing a program that uses ioctl(2) to set the >device as required. The trick is that the updated settings persist *only >as long as the file to /dev/ttyb is open*. Ttyb is mysteriously reset to >the default state immediately afterwards... >Anyone have any ideas on how to make changes persist? The serial port device driver (I think) resets the port to its default characteristics on the last close of the port. The changes to /etc/ttytab only work when the device is "on" because getty sets the port characteristics and sleeps, leaving the port open. With the entry "off", there is no getty and the port never gets set. The solution is to have some process always have the port open. A simple solution is: prompt% sleep 10000000 > /dev/ttyb & [1] nnnn prompt% stty -parenb cs8 >/dev/ttyb This isn't the best way to do this however. Unfortunately, there is no great way. Better ways include writing a small program that opens the port, then calls pause() or sends itself a SIGSTOP. Good luck! Matt Cohen <...!uunet!chron!sysnmc> Unix Systems Programmer The Houston Chronicle 801 Texas Avenue, Houston, TX 77002 USA +1 713 220 7023 "Houston's Leading Information Source"