From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12680 invoked by alias); 2 Dec 2009 09:53:43 -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: 27447 Received: (qmail 15480 invoked from network); 2 Dec 2009 09:53:40 -0000 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,PLING_QUERY, RCVD_IN_DNSWL_LOW autolearn=no version=3.2.5 Received-SPF: none (ns1.primenet.com.au: domain at csr.com does not designate permitted sender hosts) Date: Wed, 2 Dec 2009 09:53:33 +0000 From: Peter Stephenson To: zsh-workers@zsh.org Subject: Re: unable to wait on completed job [was: should $! give the pid of subshell?] Message-ID: <20091202095333.77e37678@news01> In-Reply-To: <200912010952.nB19qs51012135@news01.csr.com> References: <19213.26295.345572.732238@gargle.gargle.HOWL> <200911251748.nAPHmrCX010198@news01.csr.com> <091129211436.ZM1769@torch.brasslantern.com> <20091130183707.4f8ea36e@news01> <091130185720.ZM3782@torch.brasslantern.com> <200912010952.nB19qs51012135@news01.csr.com> Organization: CSR X-Mailer: Claws Mail 3.5.0 (GTK+ 2.12.8; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Dec 2009 09:53:33.0762 (UTC) FILETIME=[4F7E5220:01CA7335] X-Scanned-By: MailControl A-09-22-03 (www.mailcontrol.com) on 10.68.0.160 On Tue, 01 Dec 2009 09:52:54 +0000 Peter Stephenson wrote: > Bart Schaefer wrote: > > On Nov 30, 6:37pm, Peter Stephenson wrote: > > } > > } If it's only an issue for $! (lastpid internally), I think it's fairly > > } straightforward to fix. I tried to make it work even if a new process > > } with the same PID came along later. > > > > This looks reasonable, but I wonder if we should make it conditional > > on POSIX_JOBS ? > > I'm not sure what that gains, apart from an extra error message; is > there a case where it's important that exited background jobs can't be > waited for? I don't know either. I've committed it checking for POSIXJOBS only in wait, so you can set that just for the wait command and it will work. We probably need some documentation. There's a race here if process numbers are being used up megafast, but it's unlikely enough I haven't bothered mentioning it. Index: Doc/Zsh/options.yo =================================================================== RCS file: /cvsroot/zsh/zsh/Doc/Zsh/options.yo,v retrieving revision 1.86 diff -u -r1.86 options.yo --- Doc/Zsh/options.yo 21 Jul 2009 09:35:20 -0000 1.86 +++ Doc/Zsh/options.yo 2 Dec 2009 09:51:56 -0000 @@ -1324,6 +1324,11 @@ shell is saved for output within a subshell (for example, within a pipeline). When the option is set, the output of tt(jobs) is empty until a job is started within the subshell. + +When the option is set, it becomes possible to use the tt(wait) builtin to +wait for the last job started in the background (as given by tt($!)) even +if that job has already exited. This works even if the option is turned +on temporarily around the use of the tt(wait) builtin. ) enditem() -- Peter Stephenson Software Engineer Tel: +44 (0)1223 692070 Cambridge Silicon Radio Limited Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, UK Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom