From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <412467dc08b91c236bd993a38c474e0c@coraid.com>
From: erik quanstrom <quanstro@coraid.com>
Date: Fri, 19 Jan 2007 17:17:01 -0500
To: 9fans@cse.psu.edu
Subject: Re: [9fans] rx - wot no stderr?
In-Reply-To: <c6fa233e1ab2b2ee64026ecc77d26e6a@quintile.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Topicbox-Message-UUID: 06780498-ead2-11e9-9d60-3106f5b1d025

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