From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18065 invoked by alias); 20 Aug 2010 11:52:27 -0000 Mailing-List: contact zsh-users-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Users List List-Post: List-Help: X-Seq: 15304 Received: (qmail 19480 invoked from network); 20 Aug 2010 11:52:22 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.3.1 Received-SPF: none (ns1.primenet.com.au: domain at vinc17.net does not designate permitted sender hosts) Date: Fri, 20 Aug 2010 13:52:18 +0200 From: Vincent Lefevre To: zsh-users@zsh.org Subject: Re: process substitution and Ctrl-C Message-ID: <20100820115218.GC16241@prunille.vinc17.org> Mail-Followup-To: zsh-users@zsh.org References: <20100819124142.GQ16075@prunille.vinc17.org> <20100819140730.70daeb3b@csr.com> <20100819181556.4a3e6589@csr.com> <20100819211853.33d720d8@pws-pc> <100819083237.ZM26692@torch.brasslantern.com> <20100819213717.5b5a7466@pws-pc> <20100819211721.GB16241@prunille.vinc17.org> <100820011905.ZM28486@torch.brasslantern.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <100820011905.ZM28486@torch.brasslantern.com> X-Mailer-Info: http://www.vinc17.org/mutt/ User-Agent: Mutt/1.5.20-6127-vl-r38670 (2010-08-14) On 2010-08-20 01:19:05 -0700, Bart Schaefer wrote: > The process substitution can't really be synchronous in the sense of > sequential with respect to the rest of the job. The intention is to > run in parallel so that multios can send data to many processes at > once. I think the rest of the behavior was ill-defined side-effect. I don't think this is specific to process substitution. This should also be the case for pipelines, such as: prg1 | prg2 | prg3 | prg4 All of the should be run in parallel to avoid a possible deadlock due to buffering (and this should also be faster on today's desktop machines, which have several cores). But as far as I can see, a Ctrl-C interrupts all of them. > On Aug 19, 11:17pm, Vincent Lefevre wrote: > } However there's a race condition, IMHO. In fact, even without a signal > } to the main process. For instance, if you consider: > } > } ls >>(cat -n) > } > } then the zsh prompt for the next command is displayed before "cat -n" > } finishes. Does this mean that process substitution should not be used > } for filtering, except when an end marker is used (as in the example > } at the end of my message)? > > I'm not sure what question you're asking, [...] What I mean here is: the problem is that the main shell doesn't wait for "cat -n" to finish. This means that on a typical machine, the zsh prompt will here be displayed before the "cat -n" output. This should be more clear with: ls >>(sleep 2; cat -n) I would like the same behavior as: { ls } >>(sleep 2; cat -n) > } For instance: > } > } { ls } >>(while read line; do sleep 1; echo $line; done) > } > } outputs one line each second, and the main process is blocked as > } wanted; but if one does a Ctrl-C, the main process is terminated > } and one gets the prompt while the substituted process still outputs > } the remaining lines each second. I don't think this is the behavior > } that one expects. > > As noted above, that's the only behavior that could be accomodated in > the original code base ... so it _is_ what someone who has been using > zsh since 1993-ish would expect. :-) I think the average user would expect process substitution to behave a bit like pipes w.r.t. signals, e.g. like: ls | while read line; do sleep 1; echo $line; done The fact that the right part is in the foreground doesn't matter. One can see that everything is killed with a more complex one: { echo foo; sleep 5; echo bar } | \ { while read line; do sleep 1; echo $line; done; echo blah >&2 } | \ { sleep 10; read a; echo $a; sleep 2; cat } -- Vincent Lefèvre - Web: 100% accessible validated (X)HTML - Blog: Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)