From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3569 invoked by alias); 25 Oct 2014 23:17:23 -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: 33536 Received: (qmail 9802 invoked from network); 25 Oct 2014 23:17:22 -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-Originating-IP: [80.3.229.105] X-Spam: 0 X-Authority: v=2.1 cv=AoZg3YNP c=1 sm=1 tr=0 a=uz1KDxDNIq33yePw376BBA==:117 a=uz1KDxDNIq33yePw376BBA==:17 a=NLZqzBF-AAAA:8 a=kj9zAlcOel0A:10 a=bPRAPeopU76f9C7gbKQA:9 a=CjuIK1q_8ugA:10 Date: Sun, 26 Oct 2014 00:17:17 +0100 From: Peter Stephenson To: zsh-workers@zsh.org Subject: Re: bug in zsh wait builtin - rhbz#1150541 Message-ID: <20141026001717.4d4e3f5a@pws-pc.ntlworld.com> In-Reply-To: <20141026000448.12fa03fd@pws-pc.ntlworld.com> 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> <141025152827.ZM7060@torch.brasslantern.com> <141025153231.ZM19285@torch.brasslantern.com> <20141026000448.12fa03fd@pws-pc.ntlworld.com> X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.7; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Sun, 26 Oct 2014 00:04:48 +0100 Peter Stephenson wrote: > I'm now wondering whether we need > > if (!jn || (!(jn->stat & (STAT_CURSH|STAT_BUILTIN)) && > jn - jobtab != thisjob)) > addbgstatus(pid, (int)lastval2); > > i.e. if there's *no* job we should remember the PID because we don't > have enough information to say we don't need to remember it. That's > probably safe --- we've already had a succesful return value from wait > or one of its relatives so it's a child of the shell --- but there might > be cases where it's inefficient. I suppose I ought to check what > happens when job control is off. It's typically OK with job control off, there is a job at that point... I found the places where this (!jn) triggers by adding error output in this case and running the test suite... ./A02alias.ztst: starting. This test hangs the shell when it fails... *** /tmp/zsh.ztst.err.4092 Sun Oct 26 00:10:01 2014 --- /tmp/zsh.ztst.terr.4092 Sun Oct 26 00:10:01 2014 *************** *** 0 **** --- 1 ---- + pid 4118 with no job Test ./A02alias.ztst failed: error output differs from expected as shown above for: print -u $ZTST_fd 'This test hangs the shell when it fails...' alias cat='LC_ALL=C cat' cat <(echo foo | cat) So happens with <(....). ./C04funcdef.ztst: starting. *** /tmp/zsh.ztst.err.12383 Sun Oct 26 00:10:30 2014 --- /tmp/zsh.ztst.terr.12383 Sun Oct 26 00:10:30 2014 *************** *** 0 **** --- 1 ---- + pid 12454 with no job Test ./C04funcdef.ztst failed: error output differs from expected as shown above for: () (cat $1 $2) <(print process expanded) =(print expanded to file) Was testing: Process substitution with anonymous functions And =(...), not surprisingly. ./D03procsubst.ztst: starting. *** /tmp/zsh.ztst.err.12707 Sun Oct 26 00:10:31 2014 --- /tmp/zsh.ztst.terr.12707 Sun Oct 26 00:10:31 2014 *************** *** 0 **** --- 1,2 ---- + pid 12713 with no job + pid 12714 with no job Test ./D03procsubst.ztst failed: error output differs from expected as shown above for: paste <(cut -f1 FILE1) <(cut -f3 FILE2) Was testing: <(...) substitution And again. ./V08zpty.ztst: starting. *** /tmp/zsh.ztst.err.15038 Sun Oct 26 00:10:44 2014 --- /tmp/zsh.ztst.terr.15038 Sun Oct 26 00:10:44 2014 *************** *** 0 **** --- 1 ---- + pid 15042 with no job Test ./V08zpty.ztst failed: error output differs from expected as shown above for: zpty cat cat zpty -w cat a line of text var= zpty -r cat var && print -r -- ${var%%$'\r\n'} zpty -d cat Was testing: zpty with a process that does not set up the terminal: internal write So happens with processes forked by zpty. I get messages in the completion tests but no errors which I guess are also zpty. So it looks like these cases aren't relevant and we can ignore the case of no job and still pick up all the cases we do need. pws