From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19036 invoked by alias); 20 Aug 2010 15:24:45 -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: 15305 Received: (qmail 29021 invoked from network); 20 Aug 2010 15:24:39 -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,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 Received-SPF: none (ns1.primenet.com.au: domain at closedmail.com does not designate permitted sender hosts) From: Bart Schaefer Message-id: <100820082418.ZM29345@torch.brasslantern.com> Date: Fri, 20 Aug 2010 08:24:18 -0700 In-reply-to: <20100820115218.GC16241@prunille.vinc17.org> Comments: In reply to Vincent Lefevre "Re: process substitution and Ctrl-C" (Aug 20, 1:52pm) 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> <20100820115218.GC16241@prunille.vinc17.org> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: zsh-users@zsh.org Subject: Re: process substitution and Ctrl-C MIME-version: 1.0 Content-type: text/plain; charset=us-ascii On Aug 20, 1:52pm, Vincent Lefevre wrote: } Subject: Re: process substitution and Ctrl-C } } 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. } } I don't think this is specific to process substitution. This should } also be the case for pipelines [...] But as far as I can see, a } Ctrl-C interrupts all of them. Yes, obviously. The difference is that a pipeline is organized as a process group whose leader's PID is recorded in the job table, so even historically, it was all managed together as one job. Conversely, a process substitution (again historically) went into the background; the closest pipeline analogy would be prg1 | ( exec prg2 & ) Subsequent changes mean this behavior is no longer necessary, it was merely preserved so that the new code behaved like the old code. I'm not arguing that it should have been that way or should stay that way, I'm just providing context. } > On Aug 19, 11:17pm, Vincent Lefevre wrote: } > } 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. Yes, I get that; what I don't follow is what that has to do with using process substitution for filtering and whether or not there's an "end marker". Filtering implies that there's a downstream consumer of the output of the filter, and using an end marker or not won't have any effect on what's seen downstream. If you botch handling EOF from the upstream in the middle of a pipeline, you'll get the same problem you had with your process substitution (except that you'll be able to interrupt the pipeline, even in older zsh). The reason the manual explicitly calls out that process substitutions are run asynchronously is to warn you about the ( prg2 & ) behavior. We're discussing whether to change that and I think PWS's last patch does so, but in the meantime if you don't want the backgrounding effect, you're correct, you can't use a process substitution as if it were the tail of a pipeline.