From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <458a902e5883e2f125866013dbdd9fdf@coraid.com>
From: erik quanstrom <quanstro@coraid.com>
Date: Fri, 19 Jan 2007 08:07:36 -0500
To: 9fans@cse.psu.edu
Subject: Re: [9fans] rx - wot no stderr?
In-Reply-To: <599f06db0701190432qfd37963vce69c803d3ec67d1@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Topicbox-Message-UUID: 05dc537c-ead2-11e9-9d60-3106f5b1d025

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=20
the incoming call.  since it's a single Channel in the kernel, there's no=
 way=20
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.
>=20
> I always survived this redirecting error messages to a file in
> the remote command. =C2=BFIsn't that enough?.
> --=20
> - curiosity sKilled the cat