From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25106 invoked by alias); 22 Oct 2014 06:56:00 -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: 33492 Received: (qmail 1417 invoked from network); 22 Oct 2014 06:55:44 -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: <141021235542.ZM14840@torch.brasslantern.com> Date: Tue, 21 Oct 2014 23:55:42 -0700 In-reply-to: <20141021210234.199eee3d@pws-pc.ntlworld.com> Comments: In reply to Peter Stephenson "Re: bug in zsh wait builtin - rhbz#1150541" (Oct 21, 9:02pm) References: <20141021210234.199eee3d@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 21, 9:02pm, Peter Stephenson wrote: } } There's an explanatory note in the latest POSIX standard about this, } quoted below. It seems that the shell is basically required to remember } all background processes indefinitely (up to not very helpful get out } clauses). As a baseline, CHILD_MAX here is 1024. This probably needs } to be a special hash. Since you've bothered to look this up ... does it go on to say what the shell is supposed to do if PIDs roll over so that a new background job gets the same $! as some previous one? Is "kill" supposed to work the same way? (Do we need to send an inquiry to austin-group? If so, you will have to do it, my ability to post there has been messed up for a long time.) 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. } Historical implementations of interactive shells have discarded the exit } status of terminated background processes before each shell prompt. Precisely. This is not a "bug," as zsh's implementation predates 2008. It's a POSIX non-conformity, but zsh has quite a few of those remaining, I think. -- Barton E. Schaefer