How can I read keyboard without stopping

[Ronald G Minnich]

In article <13307 at mimsy.UUCP> chris at mimsy.UUCP (Chris Torek) writes:
>>(... my comment on stat() returning bytes-to-read for a terminal)
>Perhaps.  I doubt one could make much use of it, since it would change
>from moment to moment, as the user types.
Well, for one thing, it pretty much eliminates the need for FIONREAD.
Seems to me a good thing. It bugs me that there are two 
different ways to do the same thing for different types of files.
Seems to bug Peter too, so that makes two of us :-)
FIONREAD changes from moment to moment as the user types too.
>>Also, on most unix's you can't tell whether there are 0 bytes
>>to read because of an eof or 0 bytes cause nothing is there yet. 
>False.
Well, last time i tried a few years ago that was true. 
I.e. for some arbitrary file descriptor, you do a stat, 
and that stat indicates 0 bytes to read. OK, are you
at EOF, or are you at a lull in the data? Last time i looked
you couldn't tell the difference, except by doing a read. 
This was especially a pain if the file was a pipe.
Now i know about the EWOULDBLOCK business but that is non-portable.
So if you actually go to read the file to close it up you risk
being put to sleep if you are not at EOF.
   Anyway, if things have changed and there is a way to find 
you are at EOF, i would be happy to know.
So how do you (on an arbitrary file, not just terminals, now):
1) tell the difference
2) tell you are at EOF? And i mean for both blocking and non-blocking.
   I know about non-blocking.
I think you are assuming my question is differentiating EOF from 0 bytes after 
a return from a read(). My question is determining that you are
at EOF WITHOUT doing a read(). That is possible on many systems. 
I didn't think it was easily done on Unix.
inquiring minds want to know.
ron