How might this work?

[Aaron Crane]

Dirk Koopman writes:
> Isn't this just dup()? The problem you have with that is that on 
> non-seekable (or at least non-rewindable) things (like sockets), reading 
> anywhere from it will IIRC consume the data.

Sadly, it's not just dup().  Apart from the seekability issue, a dup()ed
file descriptor shares its file offset with the original; the two
descriptors are interchangeable except in their numerical value (and thus
their FD_CLOEXEC behaviour).

It's closer to the Linux behaviour of opening /dev/fd/N (also known as
/proc/self/fd/N), though that still has problems for character devices,
sockets, pipes, etc.  And don't forget that on BSD (and therefore Mac OS X),
opening /dev/fd/N is equivalent to dup() anyway, so that wouldn't be
portable.  (I don't know what non-BSD, non-Linux systems do for /dev/fd/N.)

-- 
Aaron Crane