UUCP Port Turnaround

[gemini at homxb.UUCP]

In article <13135 at sun.uucp>, guy%gorodish at Sun.COM (Guy Harris) writes:
> I'm not sure I care for the notion of something that's almost, but
> not quite, the same as "getty"; the two programs can easily get out
> of sync.  I've seen solutions proposed where you have two "devices"
> associated with a terminal port, one for dialing out and one for
> other uses.
        ... more stuff about modifiying the kernel for two devices ...

Venturcom's VENIX did (still does) have hacks like these in the kernel
tty driver.  I was never successful in getting dial-in/out to work with
either a Rixon modem, or an AT&T Aztec protocol modem, although the
claim was that they worked (mostly?) with Hayes modems.  As far as
I'm concerned, hacking the kernel ISN'T the way to go.

The HDB uugetty program also didn't turn the trick for me either.  I
gave up on that approach months ago as a waste of time.

Then, lo, out of the public domain comes "modem".  It needed just what
the author claimed: to be made aware of lock file location and naming
conventions and to know the sequence the modem uses when answering a
call.  Jeeze, that little sucker was up on my machine in an hour.
And it worked, mostly.  The only hacks I added were to not open
the serial port until after the port becomes free (to make sure the
phone gets hung up immediately after an outgoing call has finished),
and to add a "send" sequence for forcing hangup (to guarantee a clean
start for talking to the modem.  

It's short, sweet, for free, you get the source, and it works.  Save
the kernel mods for when they're really needed.  As for me, I'm happy
with two versions of 'getty'.

Rick Richardson, PC Research, Inc. (201) 922-1134, (201) 834-1378 @ AT&T-CP
..!ihnp4!castor!{rer,pcrat!rer} <--Replies to here, not to homxb!gemini, please.