brant@manta.UUCP (Brant Cheikes) (07/07/88)
In article <414@icus.UUCP> lenny@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? -- Brant Cheikes University of Pennsylvania Department of Computer and Information Science Internet: manta!brant@bpa.bell-atl.com, UUCP: {bpa,drexel}!manta!brant
ken@maxepr.UUCP (Ken Brassler) (07/10/88)
In article <385@manta.UUCP> brant@manta.UUCP (Brant Cheikes) writes: >I observed my uucico placing an outgoing call and noticed that uugetty >*was* turned off and inittab modified. >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? I believe that all the utilities supplied by AT&T use the shell scripts "geton.sh" and "getoff.sh" to bump and restore whatever flavor of getty is running on the port to be used. You can verify this by running "strings" on each of the binaries, looking for "/usr/bin/getoff.sh %s", or similiar. If you can determine that all of your communication programs will be using a port that has uugetty attached, then you can simply change /usr/bin/getoff.sh and /usr/bin/geton.sh to do nothing. Programs that use some other method, like; system("/usr/bin/setgetty ph1 0"); will still bump uugetty, but you'll be no worse off than you are now. -- Ken Brassler {ames,decwrl,pyramid,sun,lll-crg}!pacbell!maxepr!ken
kevin@kosman.UUCP (Kevin O'Gorman) (07/10/88)
In article <385@manta.UUCP> brant@manta.UUCP (Brant Cheikes) writes: >In article <414@icus.UUCP> lenny@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@kosman ) voice: 805-984-8042 Vital Computer Systems, 5115 Beachcomber, Oxnard, CA 93035