[9fans] rx - wot no stderr?

[9fans] rx - wot no stderr?

[Steve Simon]

I was surprised to find plan9's implementaion of
rx(1) and rexexec(8) don't support a seperate socket
for stderr out of the remote application.

I can see that it is not that great, but somtimes
when doing (from the manpage):

	eqn paper | rx kremvax troff -ms | rx deepthought lp

It would be nice to see your troff error messages
onscreen rather than having to collect them from the
printer.

Was the decision not to implement stderr strongly
felt, or just a case of "Its not worth the complexity"?

-Steve

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

[Gorka guardiola]

On 1/17/07, Steve Simon <steve@quintile.net> wrote:
> I was surprised to find plan9's implementaion of
> rx(1) and rexexec(8) don't support a seperate socket
> for stderr out of the remote application.
>
> I can see that it is not that great, but somtimes
> when doing (from the manpage):
>
>         eqn paper | rx kremvax troff -ms | rx deepthought lp
>
> It would be nice to see your troff error messages
> onscreen rather than having to collect them from the
> printer.

I always survived this redirecting error messages to a file in
the remote command. ¿Isn't that enough?.
-- 
- curiosity sKilled the cat

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

[erik quanstrom]

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.

- erik

On Fri Jan 19 07:35:20 EST 2007, paurea@gmail.com wrote:
> On 1/17/07, Steve Simon <steve@quintile.net> wrote:
> > I was surprised to find plan9's implementaion of
> > rx(1) and rexexec(8) don't support a seperate socket
> > for stderr out of the remote application.
> >
> > I can see that it is not that great, but somtimes
> > when doing (from the manpage):
> >
> >         eqn paper | rx kremvax troff -ms | rx deepthought lp
> >
> > It would be nice to see your troff error messages
> > onscreen rather than having to collect them from the
> > printer.
> 
> I always survived this redirecting error messages to a file in
> the remote command. ¿Isn't that enough?.
> -- 
> - curiosity sKilled the cat

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

[Steve Simon]

> 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

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

[erik quanstrom]

if you are talking to a plan 9 server, stderr already works:

	; cpu -c echo fu
	fu
	; cpu -c echo fu '>[1=2]' >/dev/null
	fu

On Fri Jan 19 09:39:07 EST 2007, steve@quintile.net wrote:
> 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

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

[Steve Simon]

> if you are talking to a plan 9 server, stderr already works:

I don'r believe it does in the way I mean. The server-side of cpu opens
/mnt/term/dec/cons for stdout and again for stderr so you cannot run a remote
program, and locally redirect its stdout and stderr (without using a
temporary file in a shared file space for one or t'other as already mentioned.

>From my earlier example

	eqn paper | cpu kremvax -c troff -ms >[2] errfile | cpu -c deepthought lp

will not put my troff errors in errfile, though I admit
this is becomming a rather contrived example.

I would like to be able to do:

	rx -l steve host program > prog.out >[2] prog.err

and I cannot.

I thought about using cpu and putting a local filesystem MBEFORE
/dev/cons but it would have to make assumptions about the order
in which the remote cpu server opened /dev/cons (stdout and stderr)
which is a bit wooly for my liking.

Its not a big deal, I just wondered if there was a reason,
and I guess the answer is, no, no big reason, just no one
wanted it enough to do the work.

-Steve

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

[erik quanstrom]

On Fri Jan 19 20:17:18 EST 2007, steve@quintile.net wrote:
> > if you are talking to a plan 9 server, stderr already works:
>
> I don'r believe it does in the way I mean. The server-side of cpu opens
> /mnt/term/dec/cons for stdout and again for stderr so you cannot run a remote
> program, and locally redirect its stdout and stderr (without using a
> temporary file in a shared file space for one or t'other as already mentioned.
>

you're right.  my example is flawed.  here's a better illustration of what's going
on:

	cpu% cpu -c echo fu '>[1=2]' ';' echo bar >[2=]
	fu
	bar

- erik

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

[ron minnich]

On 1/19/07, Gorka guardiola <paurea@gmail.com> wrote:
> I always survived this redirecting error messages to a file in
> the remote command. ¿Isn't that enough?.

sadly, no. At least for what we do. We need that stderr, we need it on
the 'local' side, note the 'remote' side, we need to be able to
seperate it out from stdout, and lots of things don't provide that,
not just rexec and cpu ...

Xcpu now does, at the request of our users.

Also, opening a second socket for stderr is really a bad idea for
n>=1024. 9p knows how to mux, so we use that nice fact.

Both rexec and cpu could make slightly more use of 9p to seperate the
two streams, I have always though. But it would take some work.

ron

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

[rog]

> I would like to be able to do:
>
> 	rx -l steve host program > prog.out >[2] prog.err
>
> and I cannot.

you can do:

	echo hello | cpu -h host -c 'wc < /mnt/term/fd/10 > /mnt/term/fd/11 >[2] /mnt/term/fd/12' <[10=0] >[11=1] >[12=2] | tr '0-9' x

you'll get the 9p ping-pong penalty, but at least it can be done.

you could run the operative part up as a script if you felt like it.
unfortunately cpu doesn't do proper argument quoting, so you run
the risk of getting unexpected results if you try to get clever.