From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3736 invoked by alias); 24 Oct 2014 08:04:39 -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: 33523 Received: (qmail 13990 invoked from network); 24 Oct 2014 08:04:37 -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=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ufGR0SALPTvKOKOW84of+LhdIDONyC9uM2De1rhvLJA=; b=Q6R8L8eaeLcmEPBrZMPOQATNMgAnbsy20qBzATquBeBjGHdxnUQS5g7NzUxpIiTYVa V3RqE9ScGRbZYtuWsw1ZVRkr6CzK1vuKkbKIWaVgzEToDOFf+WxMAyhn/HmAGoIPesEj LXY7Uor+vbMtEkSEySBuRUS8g85iZdi/FaHLrjsEsB5qlmsp8cucGZLeOeJpVUJgW3qt wQL4HRHV4nu5c3c4ydHiFuIkq/lO7j9ZjfZnLefQlCJeV1xViSgP7b66ppyho6HSuHva y0ZN5IzVQKRUvfxy+HMMCJ9Ppu0c+9+QzF+egW8kkwZLgre88DRXeKuq0GYdB1hUOsar qSpw== MIME-Version: 1.0 X-Received: by 10.170.220.8 with SMTP id m8mr3994326ykf.48.1414137872762; Fri, 24 Oct 2014 01:04:32 -0700 (PDT) In-Reply-To: <141023215041.ZM19768@torch.brasslantern.com> References: <20141021210234.199eee3d@pws-pc.ntlworld.com> <141021235542.ZM14840@torch.brasslantern.com> <20141023093232.1f4201e2@pwslap01u.europe.root.pri> <141023215041.ZM19768@torch.brasslantern.com> Date: Fri, 24 Oct 2014 10:04:32 +0200 Message-ID: Subject: Re: bug in zsh wait builtin - rhbz#1150541 From: Tim Speetjens To: Bart Schaefer Cc: zsh-workers@zsh.org Content-Type: text/plain; charset=UTF-8 > } > > } > 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. This is indeed the case, and I revised the bz report accordingly. Also, I should have mentioned https://bugzilla.redhat.com/show_bug.cgi?id=1150554 rather than the one in $subject. (1150541 is for zsh 4.3.10, which doesn't seem to have POSIXJOBS) > > } 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? I believe that reporting an error for a non-existing job like this makes sense, it just doesn't for pids obtained through $!. Kind regards Tim