>> If I'm not mistaken, an end of file is signalled by a zero-length
>> read.
>
>Mostly true.  Zero-length reads can also indicate no data available in
>nonblocking mode.
>
>> If select says the data is available for reading, and read() returns
>> zero, then the file is closed.
>
>No - just that EOF has been reached.  If a non-open file descriptor
>number is passed to select(), it returns EBADF.

What I meant was that the file descriptor had been closed at the other end, but
it's easy to read that either way.

>Note that it is also possible for select() to indicate reading is
>possible but for a read to return zero if:
>	- Another process also holds a copy of that file descriptor
>	  (eg, inherited via fork).
>	- The fd is nonblocking.
>	- The other process consumed all available data between the
>	  time select() returned and the time read() was called.

Certainly an obscure set of conditions! :-)  Which leads me to wonder; is there
another way to detect EOF on a descriptor?

>By the way, this strikes me as off-topic for tech-userlevel; it's
>actually about syscalls in general and the guts of select().  Perhaps
>tech-userlevel should be removed from the cc list?

I've removed it from the cc line.

--Ken