Path: utzoo!utgpu!water!watmath!uunet!lll-winken!killer!osu-cis!att!ihnp4!ihopa!ihop3!ihtlt!kosman!kevin From: kevin@kosman.UUCP (Kevin O'Gorman) Newsgroups: unix-pc.uucp Subject: Re: uugetty Message-ID: <437@kosman.UUCP> Date: 10 Jul 88 05:00:18 GMT References: <414@icus.UUCP> <385@manta.UUCP> Reply-To: kevin@kosman.UUCP (Root) Distribution: unix-pc Organization: K.O.'s Manor - Vital Computer Systems, Oxnard, CA 93035 Lines: 32 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