From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21933 invoked by alias); 25 Oct 2014 21:55:20 -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: 33532 Received: (qmail 17215 invoked from network); 25 Oct 2014 21:55:08 -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 X-CMAE-Score: 0 X-CMAE-Analysis: v=2.1 cv=FrayJNvv c=1 sm=1 tr=0 a=FT8er97JFeGWzr5TCOCO5w==:117 a=kj9zAlcOel0A:10 a=q2GGsy2AAAAA:8 a=oR5dmqMzAAAA:8 a=-9mUelKeXuEA:10 a=ChPw6HQyC_FJ_L_lX2sA:9 a=CjuIK1q_8ugA:10 From: Bart Schaefer Message-id: <141025145443.ZM23266@torch.brasslantern.com> Date: Sat, 25 Oct 2014 14:54:43 -0700 In-reply-to: <20141025200847.782316a4@pws-pc.ntlworld.com> Comments: In reply to Peter Stephenson "Re: bug in zsh wait builtin - rhbz#1150541" (Oct 25, 8:08pm) References: <20141021210234.199eee3d@pws-pc.ntlworld.com> <141021235542.ZM14840@torch.brasslantern.com> <20141023093232.1f4201e2@pwslap01u.europe.root.pri> <141023215041.ZM19768@torch.brasslantern.com> <20141025200847.782316a4@pws-pc.ntlworld.com> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: zsh-workers@zsh.org Subject: Re: bug in zsh wait builtin - rhbz#1150541 MIME-version: 1.0 Content-type: text/plain; charset=us-ascii On Oct 25, 8:08pm, Peter Stephenson wrote: } } Here's an implementation. I've given it the obvious finger test, but } there may be some more stressful tests we could apply. Note I'm only } recording background PIDs, since the user can't explicitly wait for } foreground PIDs; it's possible I've missed a case where something can } be in the background but that would suggest the job is wrongly recorded. I was going to ask a bunch of questions about this but in looking at the patch I realized that you determine foreground-ness at the time the job exits, not at the time it's started, so this sounds fine. Incidentally, when you ^Z the foreground job, the value of $! is not updated, so the only way to use wait is by job identifier (which is equivalent to using fg). $! finally does get updated when the job is continued with bg. (This describes the pre-33531-patch state, but I don't think the patch alters it.) } One piece of unfinished business: I think lastpid_status can go, but } the logic associated with it is rather different from what I just } implemented so I'd like some further thoughts I can't think of a case where lastpid_status would not be the same as getbgstatus(lastpid) ... I suppose you could throw in a DPUTS() to confirm that, just as a sanity check, but otherwise I concur that you can do away with lastpid_status.