From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <13426df10701202306n3284f3e0ge5bb8de042535d43@mail.gmail.com> Date: Sun, 21 Jan 2007 02:06:43 -0500 From: "ron minnich" To: "Fans of the OS Plan 9 from Bell Labs" <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=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <2c5a7c3362eeff4e33cf9c16f07a6149@quintile.net> <599f06db0701190432qfd37963vce69c803d3ec67d1@mail.gmail.com> Topicbox-Message-UUID: 06d8984e-ead2-11e9-9d60-3106f5b1d025 On 1/19/07, Gorka guardiola wrote: > I always survived this redirecting error messages to a file in > the remote command. =BFIsn'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>=3D1024. 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