input ready under UNIX(R) ??!!??

[Paul S. R. Chisholm]

In article <14173 at mimsy.UUCP>, chris at mimsy.UUCP (Chris Torek) writes:
> In article <547 at poseidon.ATT.COM> psrc at poseidon.ATT.COM
> (Paul S. R. Chisholm) writes:
> >In article <771 at necis.UUCP> rbono at 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 at mimsy.umd.edu	Path:	uunet!mimsy!chris

Paul S. R. Chisholm, psrc at poseidon.att.com (formerly psc at 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.