From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28799 invoked by alias); 7 Oct 2013 14:41:02 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Seq: 31795 Received: (qmail 2818 invoked from network); 7 Oct 2013 14:40:46 -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: <131007074049.ZM32707@torch.brasslantern.com> Date: Mon, 07 Oct 2013 07:40:49 -0700 In-reply-to: <20131007102529.5354f342@pwslap01u.europe.root.pri> Comments: In reply to Peter Stephenson "Re: No pipefail option?" (Oct 7, 10:25am) References: <20131005223159.25fea6a0@pws-pc.ntlworld.com> <131006173621.ZM31831@torch.brasslantern.com> <20131007102529.5354f342@pwslap01u.europe.root.pri> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: zsh-workers@zsh.org Subject: Re: No pipefail option? MIME-version: 1.0 Content-type: text/plain; charset=us-ascii On Oct 7, 10:25am, Peter Stephenson wrote: } } I haven't yet quite worked out why it's not possible to detect the point } at which the job is finished and examine the state at that point, so I } can't comment further, but I might look again and ask stupid questions. I don't remember clearly all the details, but it's some combination of: - because external jobs can exit and be reaped in arbitrary order, even in a pipeline, the job table is used to keep track of which position in the array to update - jobs that run in the current shell don't have a complete job table entry [cf. all the gyrations to suspend/background a loop] and aren't "reaped" in the same code path as external jobs, so the wrong array position (or none at all) may get updated - the incorrect update depends on whether the external job exited AND got reaped before the current-shell job has completed, because of the way reaping updates the job table, so correctness is unpredictable - complex commands "in the current shell" may have external subjobs that need a separate pipestatus (this applies only at end of a pipeline)