uugetty

[Kevin O'Gorman]

In article <385 at manta.UUCP> brant at manta.UUCP (Brant Cheikes) writes:
>In article <414 at icus.UUCP> lenny at icus.UUCP (Lenny Tropiano) writes:
>>While it is true that uugetty allows bi-directional traffic without turning
>>off the "getty" [...]
>
>I observed my uucico placing an outgoing call and noticed that uugetty
>*was* turned off and inittab modified.  Kevin O'Gorman's UNIXpc
>kermit port does the same thing.  So even though uugetty is supposed
>to allow bi-directional traffic, all the utilities that use the OBM
>port assume it doesn't and turn it off before opening the port.  Is
>there any way around this?

Well, if it helps you think about this, the modifications to /etc/inittab
are happening inside of /usr/bin/setgetty (which is generally called by
/usr/bin/geton.sh and /usr/bin/getoff.sh).

My port of Kermit is intended to work with the old getty as well as
setgetty, so it just goes ahead and uses getoff.sh when it wants access
to the comm line.  This has the virtue of working in either case.

I wonder, though -- is there any reason to want to 'get around' this
other than a kind of wish for elegance?  As a practical matter, the
approach seems to work, and it works for all gettys.  I would be a little
reluctant to change to a scheme that depends on trying to figure out
which getty flavor was in use before trying to get access to a line.
Remember that as far as I know, only getoff.sh would work with the original
getty.



---
Kevin O'Gorman ( kevin at kosman ) voice: 805-984-8042
  Vital Computer Systems, 5115 Beachcomber, Oxnard, CA  93035