> 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.

While it would probably be good to have the /dev/fd/ files visible under
/proc, the /dev/fd/ implementation should remain:  /proc is optional, yet
one might want to have /dev/fd/ available anyway (in fact, for production
code, /proc (as such) is of much less use than /dev/fd/).  Also, /dev/fd/
is the "published interface" for 4.4BSD (right?).  There are probably also
myriad security holes waiting to be opened up by /proc/###/fd/#:  because
the socket mechanism allows processes to pass open files in a controlled
manner, a privileged process can give a user a handle on a sensitive file
if the program making the request is properly authenticated; if that safe
program's file descriptors then become available in the filesystem, a user
can get uncontrolled access to the sensitive file.  I don't know if anything
takes advantage of this feature of sockets, but I'd hardly think flushing
it down the drain is warranted.

> 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.

Yes, it would.  Unfortunately, it opens up a 55-gallon drum full of worms.
If the program has done a stat() to find out if its standard output is a
teletype, what happens if you throw its output stream into a disk file?
Some operating systems solve this problem by providing so much encapsulation
of I/O that applications need not care about the difference between types
of output, but not UNIX.  

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

Well, I hope you don't regard these as flames, but I do think the ideas are
more trouble than they're worth.

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