On Mon, 23 May 2005, der Mouse wrote:

>> stty <whatever> </dev/dty01 runs and refuses to set anything.  Exit
>> code is 0.
>
> More likely it's setting it just fine, but when it exits, nothing has
> the tty open any longer so the settings are promptly reset back to some
> kernel defaults.  (I've had run-ins with this phenomenon myself.)

Did you find a way out ;-) ? I used the idea shown by Christos in the 
email I quoted earlier:

good=0
bad=0
while true; do
 	(stty clocal crtscts 115200; sleep 5) </dev/dty01
 	k=$!
 	</dev/dty01 >/dev/dty01 expect -f ...
 	r=$?
 	kill $k
 	if [ $r -eq 0 ]; then
 		good=$(( $good + 1 ))
 	else
 		bad=$(( $bad + 1 ))
 	fi
 	echo -e "\n\n${good}:${bad}\n"
 	sleep 1
done

which is an ugly hack but it works. Right now I am testing it by running 
it in an endless loop, checking for a simple command every 3 seconds or 
so. I got 3346 good runs and 84 bad ones so far. I will let it run till 
morning. A bad run consists in a failure of the hack above to work 
properly which causes the expect script to exit with an error code. The 
hardware is not at fault. Any ideas what to look for ? I added small 
delays a little everywhere in the expect script (esp. at start and 
exit). I also kill the background stty process pipe as shown above just 
in case.

Imho the ttys should preserve the last set state and not reset on each 
closure. Lots of apps depend on this. chat, tip, cu, pppd ...

>> /root# ls -l /dev/tty01
>> crw-rw-rw-  1 uucp  wheel  8, 1 May 21 03:50 /dev/tty01
>> /root# ls -l /dev/dty01
>> crw-rw-rw-  1 uucp  wheel  8, 524289 May 21 03:49 /dev/dty01
>>                                ^^^^^^is this not supposed to be 1?
>
> No; if it were 1, there would be no difference between /dev/tty01 and
> /dev/dty01.  The driver in question presumably pays attention to the
> 524288 bit of the minor device number.

You are right, I saw that myself.

Peter