From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9 invoked by alias); 26 Oct 2013 07:46:03 -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: 31900 Received: (qmail 28743 invoked from network); 26 Oct 2013 07:45:57 -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: <131026004551.ZM32043@torch.brasslantern.com> Date: Sat, 26 Oct 2013 00:45:51 -0700 In-reply-to: <131025162543.ZM7466@torch.brasslantern.com> Comments: In reply to Bart Schaefer "Not quite out of the pipestatus woods yet ..." (Oct 25, 4:25pm) References: <131025162543.ZM7466@torch.brasslantern.com> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: zsh-workers@zsh.org Subject: Re: Not quite out of the pipestatus woods yet ... MIME-version: 1.0 Content-type: text/plain; charset=us-ascii On Oct 25, 4:25pm, Bart Schaefer wrote: } } setopt MONITOR } } before the "stress test" in A05execution.ztst, it ends up failing most of } the time. So there is indeed still a race of some sort. Some experimentation with "set -x" and TRAPCHLD indicates that it gets pipestatus wrong if the left-hand-sides of the pipe exit while the loop body is still running. Some debugging statements added to storepipestats() indicate that the problem is that job != thisjob at the time the loop finally does exit. I think it has something to do with the oldjobtab / jobtab switching, but have not yet confirmed.