> 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
