Path: utzoo!attcan!uunet!tut.cis.ohio-state.edu!n8emr!uncle!celebr!jbm
From: jbm@celebr.uucp (John B. Milton)
Newsgroups: comp.unix.internals
Subject: Re: pty bugs & features
Message-ID: <1990Sep4.083053.4611@celebr.uucp>
Date: 4 Sep 90 08:30:53 GMT
References: <24356@adm.BRL.MIL>
Organization: Celebrezze Committee
Lines: 35

In article <24356@adm.BRL.MIL> and@ux.rfhsm.lon.ac.uk (Andy Holyer) writes:
>>>>>> On 29 Aug 90 15:44:50 GMT, Leslie Mikesell <les@chinet.chi.il.us> said:
>les> ....  The real problem is when you have
>les> placed a long distance call to or from a modem on a unix machine and
>les> pick up a ^S from line noise.  I've even seen cases where the device
>les> driver would lock up so that even a kill -9 wouldn't release the
>les> process and there was no way to drop the call without physical access to
>les> the modem.
>
>I've seen this problem quite frequently using terminals with XON/XOFF
>handshaking - I find that few sites are willing to pay for more than
>4-wire cabling IMH experience. A notable offender seems to be GNU's
>bash shell. On occasions the only way to unhang a line is to reboot
>(sometimes, I've even known a *power*down* to be necessary :-( )
>Is there a less drastic solution?
>...

Yes. I have a program I call "clocal" that is a tool for messing about with
ports. It has tons of error messages and signal handling, but it boils down
to this:

#include <fcntl.h>
#include <termio.h>
  f=open(line,O_RDONLY|O_NDELAY); /* always succeeds */
  ioctl(f,TCXONC,1); /* restart the UNIX side */
  ioctl(f,TCXONC,3); /* send a ^Q to the terminal */

On some SYSVs the driver does not handle NDELAY properly and the port will
become a tar baby. Any process that opens the port is stuck to it until reboot.
Some drivers will hang in the first ioctl.

John
-- 
John Bly Milton IV, jbm@uncle.UUCP, n8emr!uncle!jbm@osu-cis.cis.ohio-state.edu
(614) h:252-8544, w:469-1990; N8KSN, AMPR: 44.70.0.52; Don't FLAME, inform!