Path: utzoo!yunexus!geac!syntron!jtsv16!uunet!ncrlnk!ncr-sd!hp-sdd!ucsdhub!ucsd!rutgers!att!poseidon!psrc From: psrc@poseidon.ATT.COM (Paul S. R. Chisholm) Newsgroups: comp.unix.questions Subject: Re: input ready under UNIX(R) ??!!?? Summary: avoiding fcntl(2) headaches Keywords: input, unix, help Message-ID: <551@poseidon.ATT.COM> Date: 28 Oct 88 20:16:05 GMT Article-I.D.: poseidon.551 References: <771@necis.UUCP> <547@poseidon.ATT.COM> <14173@mimsy.UUCP> Organization: AT&T Bell Laboratories Lines: 35 In article <14173@mimsy.UUCP>, chris@mimsy.UUCP (Chris Torek) writes: > In article <547@poseidon.ATT.COM> psrc@poseidon.ATT.COM > (Paul S. R. Chisholm) writes: > >In article <771@necis.UUCP> rbono@necis.UUCP (Rich Bono) writes: > >>HELP!! how can one (if at all) find out (non-destructivly) if there is > >>any input waiting to be read from stdin??? ... Clearing ICANON ... > (so what is comp.lang.c doing in the header?). I have redirected followups. Hey, the question started there. I was the one who added comp.unix.questions in the first place. (And this is me being quoted in this next paragraph.) > >[fcntl O_NDELAY] (If you're paranoid that the child might die, dup(2) > >file descriptor zero, close(2) file descriptor zero, dup() the copy > >(which will become file descriptor zero), and close() the copy. The > >child process now has its own file descriptor for standard input.) > > This will not do any good: dup()ed file descriptors share the same > file table entry, and the O_NDELAY flag sits in the file table entry. > Remember, child processes get dup()s of the parent's descriptors in > the first place. Oops, right. What I *really* did was run "foo In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) >Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris Paul S. R. Chisholm, psrc@poseidon.att.com (formerly psc@lznv.att.com) AT&T Bell Laboratories, att!poseidon!psrc, AT&T Mail !psrchisholm I'm not speaking for the company, I'm just speaking my mind. UNIX(R) is a registered trademark of AT&T.