Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!hao!ames!ptsfa!hoptoad!academ!killer!jfh
From: jfh@killer.UUCP (John Haugh)
Newsgroups: comp.bugs.sys5
Subject: Re: CLOCAL, or catch-22
Message-ID: <1312@killer.UUCP>
Date: Sat, 8-Aug-87 13:09:31 EDT
Article-I.D.: killer.1312
Posted: Sat Aug  8 13:09:31 1987
Date-Received: Mon, 10-Aug-87 00:14:06 EDT
References: <325@nsta.UUCP> <25073@sun.uucp> <3607@sdcsvax.UCSD.EDU> <326@nsta.UUCP>
Organization: Big "D" Home for Wayward Hackers
Lines: 31
Summary: UYFB.

In article <326@nsta.UUCP>, amos@nsta.UUCP (Amos Shapir) writes:
> Specifying O_NDELAY solves the problem for  one process, but it does not
> help if one does not have the source; some system programs that do their
> own ioctl's (most notably, /etc/getty), will let you specify some of the
> ioctl  flags according  to your  local configuration,  but not  the open
> flags.
> 
> The problem  essentially is: How  do you convince  getty to open  a port
> without  waiting for  carrier, if  you do  not have  the carrier  signal
> wired, and your terminal driver expects  to see it before proceeding? (I
> do not claim there is no way, I'm rather new to sys V.3).

Ok, failing the O_NDELAY approach, how about something typically more
Unix-like.  Try a kluge.

Have a program (that you write) open the port, with O_NDELAY set, and
then set CLOCAL, close the port and exec getty.  If you get real lucky,
the driver might just be nice the next time around on the open (when
getty does it) and not require the O_NDELAY flag.

I can't _prove_ that this is going to work since some Unix's out of my
past reset the termio values to a default when you open the port.  But
if it don't work because the flags are being reset, then I'm sure you
can come up with a clever collection of forks and what not that will ...

- John.
-- 
John F. Haugh II		HECI Exploration Co. Inc.
UUCP:	...!ihnp4!killer!jfh	11910 Greenville Ave, Suite 600
"Don't Have an Oil Well?"	Dallas, TX. 75243
" ... Then Buy One!"		(214) 231-0993