Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!bloom-beacon!mit-eddie!rutgers!uwvax!oddjob!mimsy!chris
From: chris@mimsy.UUCP (Chris Torek)
Newsgroups: comp.unix.wizards
Subject: Re: How can I read keyboard without stopping
Keywords: curses keyboard
Message-ID: <13333@mimsy.UUCP>
Date: 1 Sep 88 02:10:46 GMT
References: <813@ms3.UUCP> <1246@mcgill-vision.UUCP> <669@super.ORG> <679@super.ORG>
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 68

>>>(... comment on stat() returning bytes-to-read for a terminal)

>In article <13307@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes:
>>Perhaps.  I doubt one could make much use of it, since it would change
>>from moment to moment, as the user types.

In article <679@super.ORG> rminnich@super.ORG (Ronald G Minnich) writes:
>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.

The difference (or so it seems to me) is that FIONREAD is implicitly
defined as st.st_size - current_seek_offset, so that it makes sense for
it to change as you read data.  But seek offsets are peculiar on ttys.
Hence `perhaps'....

At any rate, no one ever seems to use the value from FIONREAD as anything
other than a ready/not-ready flag, and here select does the job.

>>>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.

This paragraph seems hopelessly confused.  stat says how big the file
is, and is completely orthogonal to your current seek offset.  And I
thought we were talking about tty devices, not pipes.

>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.

Use select (or, in SysV, poll, except that it only works on STREAMS).
Select says that you can read or write exactly when that read or write
would not block (not that it would necessarily succeed).

>   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):

(Changing the rules again, but okay:)

>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.

On regular files, you are at EOF if your current seek offset (available
via lseek()) matches the size returned via fstat().  Tty devices do not
have ends-of-files; instead, some peculiar creature types some special
character to pretend an end of file, and naturally this is
unpredictable.  `On many systems' there are no special files (ttys,
pipes, etc) and the question never even comes up.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris@mimsy.umd.edu	Path:	uunet!mimsy!chris