From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25353 invoked by alias); 15 Oct 2013 14:29:44 -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: 18032 Received: (qmail 12510 invoked from network); 15 Oct 2013 14:29:38 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) 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.2 From: Bart Schaefer Message-id: <131015072947.ZM1984@torch.brasslantern.com> Date: Tue, 15 Oct 2013 07:29:47 -0700 In-reply-to: <20131015094248.1cb9611d@pwslap01u.europe.root.pri> Comments: In reply to Peter Stephenson "Re: process substitution bug with set -e?" (Oct 15, 9:42am) References: <20131014124126.GA31070@ypig.lip.ens-lyon.fr> <20131014144838.6ec034dd@pwslap01u.europe.root.pri> <20131014150845.GB31070@ypig.lip.ens-lyon.fr> <20131014172854.70e2c3ce@pwslap01u.europe.root.pri> <131014104749.ZM591@torch.brasslantern.com> <20131015094248.1cb9611d@pwslap01u.europe.root.pri> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: zsh-users@zsh.org Subject: Re: process substitution bug with set -e? MIME-version: 1.0 Content-type: text/plain; charset=us-ascii On Oct 15, 9:42am, Peter Stephenson wrote: } } What scope should be trying to cover here? Simply document for process } substiution that if the code to which the substitution applies exits } early the shell won't wait for it to finish? Or can we infer something } a bit wider? I think we should be able to say something more general about the behavior of "exit" with respect to asynchronous jobs, and that ERR_EXIT has the same behavior. There's a little about this in the "Jobs" section but it only references explicitly backgrounded jobs and the HUP signal/option, not about implicitly asynchronous jobs. For example, note that multios and process substitutions are "disowned" in the sense that they don't get HUP'd (they also don't get TTOU'd, but aren't able to read from the terminal as far as I can tell [I/O error]). We could further explain the generality that any pair of jobs that act as a reader and a writer -- multios, process substitutions, pipes, are there more? -- have to be run in parallel to avoid deadlock, which means that at least one of each such pair is "implicitly asynchronous" in the sense I used above. Yeah, that's a misuse of "implicit" because the user has of course explicity written >>(...) or whatever, so maybe there's another way to say it. I suppose the tail end of the "Jobs" section is the right place to put this, even though that's somewhat distant from the descriptions of the syntax that evoke the behavior.