Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!sharkey!mcf!teemc!fmeed1!wehr
From: wehr@fmeed1.UUCP (Bruce Wehr)
Newsgroups: comp.sys.hp
Subject: Re: uugetty doesn't print /etc/issue (HP-UX 6.5)
Message-ID: <3645@fmeed1.UUCP>
Date: 30 Aug 89 14:19:39 GMT
References: <3628@fmeed1.UUCP> <1080078@hpfcmgw.HP.COM>
Organization: Ford Electronics Division, Dearborn MI
Lines: 31

In article <1080078@hpfcmgw.HP.COM>, rdg@hpfcmgw.HP.COM (Rob Gardner) writes:
> > uugetty should be used when a TTY port is shared for dial-in & dial-out.
> > uugetty understands about uucp lock files and will defer to a uucp dial-out.
> > getty can and usually does "get in the way".
> 
> It shouldn't. [...]
> [...] uucp or cu will be shut out while a live
> incoming call is in progress.

Live incoming calls do not create lock files.  While an open will fail
if an incoming call is in progress, cu reports 'line problem' instead of
the more appropriate 'device not available' (which it *would* report if
there was a lock file).  We also have some utilities that check for the
presence of lock files.

We *have* been using HP-UX's method of dial-in/dial-out port control.
In addition, our /etc/profile creates a lock file for users logging on,
and traps log-offs to run a script that removes them.  This has been
sufficient until I started allowing incoming uucp calls (since uucico is
the 'users' login program, instead of sh or ksh, no lock files are
created).  uugetty solves this problem by creating a lock file whenever
is detects anyone logging in.

I hope this clarifies the reason for using uugetty.  Now, if only
someone would answer the original question :-) (why doesn't uugetty
print /etc/issue?).
-- 
	       Bruce Wehr (wehr%dptc.decnet@srlvx0.srl.ford.com)
    (...!mailrus!sharkey!fmeed1!wehr) (wehr%fmeed1.uucp@mailgw.cc.umich.edu)
		   Ford Motor Company - Electronics Division
  17000 Rotunda Drive, DPTC Room LN081, Dearborn, Michigan 48121 (313)845-3039