Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!nrl-cmf!cmcl2!rutgers!ucsd!ucsdhub!esosun!seismo!uunet!super!rminnich
From: rminnich@super.ORG (Ronald G Minnich)
Newsgroups: comp.unix.wizards
Subject: Re: How can I read keyboard without stopping
Keywords: curses keyboard
Message-ID: <689@super.ORG>
Date: 2 Sep 88 14:43:30 GMT
References: <813@ms3.UUCP> <1246@mcgill-vision.UUCP> <1988Aug15.130550.8571@ateng.uucp> <1267@ficc.UUCP> <669@super.ORG> <4617@cbmvax.UUCP>
Sender: uucp@super.ORG
Reply-To: rminnich@metropolis.UUCP (Ronald G Minnich)
Organization: Supercomputing Research Center, Lanham, MD
Lines: 26

In article <4617@cbmvax.UUCP> ditto@cbmvax.UUCP (Michael "Ford" Ditto) writes:
>In article <669@super.ORG> rminnich@metropolis.UUCP (Ronald G Minnich) writes:
>>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. 
>But these are exactly the same condition.  Typing EOF on a tty in
> ... good explanation of how the read() tells you what's going on.

Sure, you can tell lots of things from the return of a read(). 
As i understood the original question it was what you 
could determine WITHOUT doing the read(). There are cases where 
you don't want to read without knowing whether you will block. 
That's why people use FIONREAD (which not everyone supports), or 
select (ditto), or in this case stat(). Or all the other 
not-quite-universal mechanisms.

There is a way to tell you are at eof, btw. ON 4.2-style systems, 
do a select on the file descriptor, and see if it returns indicating
'something there'. Then do an ioctl(fildes, FIONREAD, &length) and 
see if length is zero. If it is, the system is telling you:
there is something you can read, but you won't get anything, i.e. eof.
It is also telling you that you will return immediately if you do read.
SO, do a read(fildes, buf, 1), get the EOF indication back, fildes is
now closed. 
   This works on pipes (i.e. sockets) and ttys. I never got
around to trying it on files.
ron