psrc@poseidon.ATT.COM (Paul S. R. Chisholm) (10/29/88)
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 </dev/tty" instead of "foo". Similarly, the program could close() file descriptor zero and open() "/dev/tty" again. (Then 0, 1, and 2 aren't the same, even if they weren't originally. That may or may not be a big deal.) >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.