Path: utzoo!utgpu!water!watmath!uunet!labrea!rutgers!mailrus!ames!zorch!pacbell!maxepr!ken From: ken@maxepr.UUCP (Ken Brassler) Newsgroups: unix-pc.uucp Subject: Re: uugetty Message-ID: <515@maxepr.UUCP> Date: 9 Jul 88 22:18:52 GMT References: <414@icus.UUCP> <385@manta.UUCP> Reply-To: ken@maxepr.UUCP (Ken Brassler) Distribution: unix-pc Organization: Brassler Engineering Co., Mill Valley, CA Lines: 27 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