How might this work?

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