From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2370 invoked by alias); 24 Oct 2014 04:50:52 -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: 33521 Received: (qmail 11144 invoked from network); 24 Oct 2014 04:50:49 -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=R6+0wmVS c=1 sm=1 tr=0 a=FT8er97JFeGWzr5TCOCO5w==:117 a=FT8er97JFeGWzr5TCOCO5w==:17 a=kj9zAlcOel0A:10 a=q2GGsy2AAAAA:8 a=oR5dmqMzAAAA:8 a=-9mUelKeXuEA:10 a=9_0aVxZKOJC5a0563EwA:9 a=CjuIK1q_8ugA:10 From: Bart Schaefer Message-id: <141023215041.ZM19768@torch.brasslantern.com> Date: Thu, 23 Oct 2014 21:50:41 -0700 In-reply-to: <20141023093232.1f4201e2@pwslap01u.europe.root.pri> Comments: In reply to Peter Stephenson "Re: bug in zsh wait builtin - rhbz#1150541" (Oct 23, 9:32am) References: <20141021210234.199eee3d@pws-pc.ntlworld.com> <141021235542.ZM14840@torch.brasslantern.com> <20141023093232.1f4201e2@pwslap01u.europe.root.pri> 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 23, 9:32am, Peter Stephenson wrote: } } On Tue, 21 Oct 2014 23:55:42 -0700 } Bart Schaefer wrote: } > Is "kill" supposed to work the same way? } } There's no indication kill needs to have this. Presumably this is } because for kill you don't need to have a sensible exit status, just a } reasonable likelihood the job is dead (or wedged in some state where } that signal doesn't work, but that's an entirely different problem). My implied point was that both commands accept either job identifiers (%3, %?sleep?) or PIDs and presumably should act the same way for the same child process regardless of how it was identified; or else PIDs are something entirely different than job identifiers and the rules are different. But for "wait" treat PIDs magically while "kill" does not, seems inconsistent. } > Note also that this is partly handled by the POSIX_JOBS option: } > } > When the option is set, it becomes possible to use the wait } > builtin to wait for the last job started in the background (as } > given by $!) even if that job has already exited. This works even } > if the option is turned on temporarily around the use of the wait } > builtin. } > } > I would say that any further change made for this should also be under } > the auspices (so to speak) of POSIX_JOBS. } } That would already cover the cases in the "bug" report, in fact. I don't think it would, because the report starts two background jobs and then waits for the one started first. The current implementation only allows the most recent $! to be waited for after it exits. } I'm not really sure why we wouldn't just implement this particular } feature generally, despite the current status. Is there any reason why } you'd *want* "wait" to give you an error (which isn't a particularly } useful message) owing to a race condition you can't control? There are a lot of error messages that a script probably doesn't want but an interactive user might. Why do you want "wait %3" to report "%3: no such job"? If nobody wants it, why did it take us 25 years to figure that out? Maybe there should just be an option to never remove job table entries until "wait" is explicitly called (and MONITOR + NOTIFY constitutes an implicit wait). Then even $pipestatus could be updated at wait-time for backgrounded pipelines. (I'm not seriously suggesting that, just running this train out to the last station. Keeping job table entries around would solve the storage problem, but job table entries get made for things like brace expressions for which "wait" makes no sense, and managing pipestatus is a bear we only recently wrestled.) OK, I'm done making up odd metaphors now. Carry on.