From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <zsh-workers-return-31898-mason-zsh=primenet.com.au@zsh.org>
Received: (qmail 14684 invoked by alias); 25 Oct 2013 17:05:16 -0000
Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm
Precedence: bulk
X-No-Archive: yes
List-Id: Zsh Workers List <zsh-workers.zsh.org>
List-Post: <mailto:zsh-workers@zsh.org>
List-Help: <mailto:zsh-workers-help@zsh.org>
X-Seq: 31898
Received: (qmail 10626 invoked from network); 25 Oct 2013 17:05:10 -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 <schaefer@brasslantern.com>
Message-id: <131025100445.ZM9154@torch.brasslantern.com>
Date: Fri, 25 Oct 2013 10:04:45 -0700
In-reply-to: <20131025162146.459b92c2@pwslap01u.europe.root.pri>
Comments: In reply to Peter Stephenson <p.stephenson@samsung.com>
 "Re: Shell job structure" (Oct 25,  4:21pm)
References:
 <CADv1Z=pM7H4Xg9+GyWd4zw0cv0mXfbJvqip6vc7e_yrXRN=1sg@mail.gmail.com>
	<20131005223159.25fea6a0@pws-pc.ntlworld.com>
	<131006173621.ZM31831@torch.brasslantern.com>
	<20131007102529.5354f342@pwslap01u.europe.root.pri>
	<131007074049.ZM32707@torch.brasslantern.com>
	<20131008214437.41dc396a@pws-pc.ntlworld.com>
	<131024220214.ZM8256@torch.brasslantern.com>
	<20131025110056.1757a5ab@pwslap01u.europe.root.pri>
	<131025081311.ZM9080@torch.brasslantern.com>
	<20131025162146.459b92c2@pwslap01u.europe.root.pri>
X-Mailer: OpenZMail Classic (0.9.2 24April2005)
To: zsh-workers@zsh.org
Subject: Re: Shell job structure
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii

On Oct 25,  4:21pm, Peter Stephenson wrote:
}
} > % false | true | false | while true | false | true; do print $pipestatus; break; done; print $pipestatus
} > 0 1 0
} > 1 0 1 0
} 
} That's the sort of thing I'm worrying about.  As long as it can identify
} succesfully which job it needs to worry about at any time, it should be
} OK.

Every entry in $pipestatus except the very last one is copied from a
"Process" structure in the Job "procs" list, so as long as child reaping
updates the correct Process (which seems to be pretty solid or we'd have
scads of other problems) there's only that last slot to worry about.

The global "lastval" is used to populate that final slot when the command
is executing in the current shell.  That's a bit fragile and somewhat
backward because in all other cases the status that goes into pipestats
is also used to *assign* lastval -- it's just this "optimized" case where
we assume lastval has already been set correctly.

This is why update_job() has to skip PIPEFAIL handling and leave that to 
printjob(), so they don't use lastval in the wrong order.