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