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: <687@super.ORG>
Date: 2 Sep 88 12:33:05 GMT
References: <813@ms3.UUCP> <1246@mcgill-vision.UUCP> <669@super.ORG> <679@super.ORG> <13333@mimsy.UUCP>
Sender: uucp@super.ORG
Reply-To: rminnich@metropolis.UUCP (Ronald G Minnich)
Organization: Supercomputing Research Center, Lanham, MD
Lines: 48

In article <13333@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes:
>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.
Well, ok, looking at stat i see:
               off_t  st_size;/* total size of file, in bytes */
So what can i say? Looks like the size to me. First time i saw this
i thought 'well, terminals aren't regular files, so i guess
they stuff the amount of characters in the queue in here'. 
And it still seems reasonable to me.
>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.
I often use it as a way of determining how many bytes to 
read from the tty. I have gotten very good performance this way.
I.E. I can suck up a lot of 9600 baud input even on a VAX.
I have fixed a lot of people's programs just by changing
single-character reads to FIONREAD-driven reads.
> ... more stuff.
   I think Peter and I were both bothered by having two different
mechanisms for the same function for two different file types.
I was also thinking of the number of OSs that solve all this 
more intelligently than Unix. E.G. Burroughs MCP and the Amiga OS.
   I notice through your reply a pattern: 
'oh, we were talking about ttys, not pipes'
'oh, on 4bsd do this, on Sys V do this, except for STREAMS only'
'on regular files, do this, on ttys, no eof ...'
For example:
>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).
>On regular files, you are at EOF if your current seek offset (available
but not on pipes or ttys. OK, no problem, I knew all that stuff 
already. What's wrong with a simple predicate: eof(fildes)?
Then you don't HAVE to know all this crap. Especially nice if you
are working from an inherited file descriptor. Failing that, wouldn't
it be nice if stat() were a little more informative?
   For what it is worth, you can use the st_size from stat()
to figure out how much to read from a pipe. That's the most
portable way i have found. That is why i was referring to 
st_size as the amount available to read- i was not clear on that, sorry.
   Now at some point st_size on a pipe will go to zero. 
Question is, what does that mean? That the pipe has closed? 
Or that there is nothing to read, come back later? I have a way
of determing that using select() and FIONREAD, but it is not real pretty.
   And i don't think Peter's main point was about tty's. I think it was
questioning the need for FIONREAD, given that the functionality
is just about there in stat().
   ron