I thought of an interesting idea or two. This is probably not the exact
most appropriate list to send it to, but I consider it impolite
to post to a list that I don't read. If this has been discussed
before, please flame gently ;-)

The procfs (/dev/fd mainly) seems to be more sensible as a subdirectory
of /proc/<processid>. (I'll refrain from saying that this is what
Linux does, because it does not seem to have the semantics I will
suggest below; an open on such a file apparently makes a non-shared copy).

Doing an open on /proc/327/fd/1 is equivalent with doing a dup on it,
except that you are not limited to dupping your own fds. (Perhaps an
ioctl interface can be done as well, or an ioctl could be used to
select shared references or copies on open(), this obviously needs some
thought).  Now you can already add data to some other process' stdout,
or steal data from its stdin.  (note that creating non-shared copies of
the fd is also useful, see below)

But one of the things I've always wanted to do to was to change the
object some fd refers to after the fact. For instance, if I started
some command 'verbose_command &' and I forgot the redirection. To be
able to change its stdout to some file would be very nice. So I would
propose some operation similar to dup2(oldfd, newfd), call it
forcedup(oldfd, newfd) for now.  If you already have the newfd open
(usually the case if you invoke this function) the newfd would not be
closed, but instead the underlying object would closed and then be made
to refer to the same object as oldfd (either by copying stuff over the
vnode of newfd, or by changing all references, whichever is easier).
This would not break the sharing of objects between processes, like
dup2() does.

Now if you can also still make non-shared references to an existing
object (i.e., that won't be affected by this forcedup() operation),
then you can tap all i/o through some process' fd by 1.
open("/proc/<pid>/fd/<fd>")ing it, 2. making a non-shared copy for your
own use, 3. force a pipe instead of the original fd, 4. read from
pipe/write to copied fd and/or vice-versa.

Now, am I going to get flamed for these silly ideas? ;-)

-Olaf.
--
___ Olaf 'Rhialto' Seibert                                 rhialto@mbfys.kun.nl
\X/ An original idea. That can't be too hard. The library must be full of them.

------------------------------------------------------------------------------