>>> Ideally the process will exit as soon as the user stops the
>>> transfer, but [...]
>> if you're only ever writing to the socket and don't expect to ever
>> read from it, then selecting on the socket for reading will return
>> instantly after it's been closed.

True.  This may be the best way.

>> or, selecting on it for writing will return instantly (but will
>> result in a sigpipe) after it's been closed.

> I decided to watch the result of a select (with no timeout) on the
> socket.  Strangly enough, selecting for write doesn't seem to do
> anything when the socket is closed (doesn't generate SIGPIPE),

I think the person who wrote that was being a little too elliptical.
select() does not generate SIGPIPE; rather, select() should indicate
that the socket is ready for write, and a following write() attempt
actually raises SIGPIPE (and returns EPIPE if SIGPIPE is blocked or
ignored).

> however, selecting for read does show that data is available (EOF)
> when the socket is closed.  So I just setup a 1 second timer that
> allways checks if it can read from the socket (it's normally write
> only), and if it reads an EOF it bails.

I don't see the need for the timer, but shrug...

> Interestingly enough, ferror and feof both return 0 after EOF is read
> (shouldn't one be true?).

ferror and feof work on stdio streams.  select, read, and write work on
file descriptors.  There is no stdio analog to select(); I can't even
see one in the NetBSD extensions to standard stdio.  If you read EOF
via read(), stdio won't know anything about it.

					der Mouse

			       mouse@rodents.montreal.qc.ca
		     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B