Re: [9fans] rx - wot no stderr?

["Steve Simon" <steve@quintile.net>]

> rexexec(8) doesn't have anything to do with supporting stderr.
> listen does this work.  (assuming a p9 system not using ssh to connect.)
> /sys/src/cmd/aux/listen.c:/^newcall dup(2)'s all three descriptors from
> the incoming call.  since it's a single Channel in the kernel, there's no way
> to differentiate writes on fd 0, 1 or 2.  if you want that, you need
> to mux and demux the filedescriptors onto some protocol.

Agreed, however the old BSD rexec protocol has hooks for a seccond
socket connection called back from the server to support stderr.
It is an optional enhancement and though plan9's rx(1) does support BSD
compatibility, doesn't support this feature; and yes it would open the
same old wounds that ftp's passive mode was designed to heal :-)

My question (perhaps badly phrased) was more about the decision not to
support stderr, why was it done? In a pure plan9 enviroment we already have
a protocol to mux and demux file descriptors as demonstarted in cpu(1).

On a similar topic a file like /dev/cpunote could forwarward notes to
the remote process to ensure it dies when told to rather than assuming
it will see an EOF on its input one day.

Was it just too much hassle for too little reward or am I missing someting,
is there a good reason why this just cannot work.

-Steve