[9fans] rx - wot no stderr? - Plan9

This is a discussion on [9fans] rx - wot no stderr? - Plan9 ; 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 ...

+ Reply to Thread
Results 1 to 10 of 10

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

  1. [9fans] rx - wot no stderr?

    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

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

    On 1/17/07, Steve Simon 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

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

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


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

    > 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

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

    Steve Simon 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).


    Yes, multiplexing the file descriptors was the first thing that
    occurred to me when I read the original posting. If the rx
    facility has to be compatible with some predefined protocol,
    that's one thing, but if it uses a new protocol it might be
    better to include the standard error stream.

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

    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


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

    > 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

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

    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

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

    On 1/19/07, Gorka guardiola 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

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

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


+ Reply to Thread