Hardware manual

it's a setting not allowed in raw mode).
This situation can create problems. For example, suppose you corrupt your terminal interface. To restore it
you go to another terminal and "stty -F dev/ttyS1 sane" (or the like). It will not work! Of course you can try to
type "stty sane ..." at the terminal that is corrupted but you can't see what you typed. All the above not only
applies to dumb terminals but to virtual terminals used on a PC Monitor as well as to the terminal windows in
X. In other words, it applies to almost everyone who uses Linux.
Luckily, when you start up Linux, any file that runs stty at boot-time will likely deal with a terminal (or serial
port with no terminal) that has no shell running on it so there's no problem for this special case.
Where to put the stty command ?
Should you need to have stty set up the serial interface each time the computer starts up then you need to
put the stty command in a file that will be executed each time the computer is started up (Linux boots). It
should be run before the serial port is used (including running getty on the port). There are many possible
places to put it. If it gets put in more than one place and you only know about (or remember) one of those
places, then a conflict is likely. So make sure to document what you do.
One place to put it would be in the same file that runs setserial when the system is booted. The location is
distribution and version dependent. It would seem best to put it after the setserial command so that the low
level stuff is done first. If you have directories in the /etc tree where every file in them is executed at
boot-time (System V Init) then you could create a file named "stty" for this purpose.
Obsolete redirection method
Prior to about 2000 you needed to use the redirection operator "<" if you wanted to use stty on a foreign
terminal. For example to use stty on ttyS2 sitting at tty1 you would type: stty .... < /dev/ttyS2. After 2000
(provided your version of setserial is >= 1.17 and stty >= 2.0) a better method was created using the -F option:
stty -F /dev/ttyS2. This will work when the old redirection method fails.
The old redirection example above makes ttyS2 the standard input to stty. This gives the stty program a link to
the "file" ttyS2 so that it may "read" it. But instead of reading the bytes sent to ttyS2 as one might expect, it
uses the link to find the configuration settings of the port so that it may read or change them. In olden days,
some people tried to use ``stty ... > /dev/ttyS2'' to set the terminal. This didn't work. Instead, it takes the
message normal displayed by the stty command for the terminal you are on (say tty1) and sends this message
to ttyS2. But it doesn't change any settings for ttyS2.
Here's a problem with the old redirection operator (which doesn't happen if you use the newer -F option
instead). Sometimes when trying to use stty, the command hangs and nothing happens (you don't get a prompt
for a next command even after hitting <return>). This is likely due to the port being stuck because it's waiting
for one of the modem control lines to be asserted. For example, unless you've set "clocal" to ignore modem
control lines, then if no CD signal is asserted the port will not open and stty will not work for it (unless you
use the newer -F option). A similar situation seems to exist for hardware flow control. If the cable for the port
doesn't even have a conductor for the pin that needs to be asserted then there is no easy way to stop the hang.
One way to try to get out of the above hang is to use the newer -F option and set "clocal" and/or "crtscts" as
needed. If you don't have the -F option then you may try to run some program (such as minicom) on the port
that will force it to operate even if the control lines say not to. Then hopefully this program might set the port
so it doesn't need the control signal in the future in order to open: clocal or -crtscts. To use "minicom" to do
Serial HOWTO
Two interfaces at a terminal 50