From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10081 invoked by alias); 10 Dec 2011 18:15:15 -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: 29981 Received: (qmail 23334 invoked from network); 10 Dec 2011 18:15:12 -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.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.2 Received-SPF: neutral (ns1.primenet.com.au: 74.125.82.43 is neither permitted nor denied by SPF record at ntlworld.com) X-ProxyUser-IP: 86.6.29.42 Date: Sat, 10 Dec 2011 18:15:03 +0000 From: Peter Stephenson To: zsh-workers@zsh.org Subject: Re: Bug in sh emulation Message-ID: <20111210181503.12e4b2ab@pws-pc.ntlworld.com> In-Reply-To: <111209194044.ZM5067@torch.brasslantern.com> References: <111209184747.ZM5000@torch.brasslantern.com> <111209194044.ZM5067@torch.brasslantern.com> X-Mailer: Claws Mail 3.7.9 (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 Fri, 09 Dec 2011 19:40:44 -0800 Bart Schaefer wrote: > On Dec 9, 6:47pm, Bart Schaefer wrote: > } > } I don't see any recent changes in exec.c that would have > } an effect on when a job is made ASYNC. > > Unless this? > > Anyway the change in question is really from 15301, which removes the > ESUB_ASYNC from a bunch of entersubsh() calls. Two of those have reappeared and reappearing the third doesn't seem to help. The problem appears to have come in between 4.3.10 and 4.3.11. It's not in 4.3.10 (2009-06-01) but is in a 4.3.10-dev-1 I have, which would be just before I changed the version to 4.3.10-dev-2 (2010-07-25). I think it's probably the set of changes around 27100 to 27109 that allowed MONITOR to remain on in a subshell. In particular, if (!isset(POSIXJOBS)) opts[MONITOR] = 0; (now) at line 974 of exec.c. Commenting out the "if" line makes the problem goes away. Allowing MONITOR in subshells was done tentatively to see if it caused problems. I suppose the real surprise is it's taken over two years for one to turn up. So the bug is caused by a combination of having the option set in a subshell and preexisting code that doesn't properly support it. > It's stuck in an infinite TTOU/CONT loop because for some reason it > wants to attachtty(), which it can't because it's not the process leader > (the parent shell still in the foreground is). Note that this attachtty() is above the point where we set MONITOR to 0 if not POSIXJOBS, so this is occurring on a later fork --- indeed, we need to remember that the problem only occurs with a pipeline in the subshell. My session / process group / controlling terminal understanding is distinctly ropey. Is the fix that we simply don't execute that code if we've already executed it, i.e. subsh is already 1 when we get there (see ultra-ultra-tentative patch --- we set subsh to 1 just after that)? That fixes the problem, but that may be simply because we don't execute the code that fails. But what should actually happen if we have a subshell of a subshell, i.e. a nested "( ... )"? And what should the group leader be set to at this point after a second fork? P.S. somewhere high on the list of things we desperately need is a set of interactive tests. Index: Src/exec.c =================================================================== RCS file: /cvsroot/zsh/zsh/Src/exec.c,v retrieving revision 1.205 diff -p -u -r1.205 exec.c --- Src/exec.c 26 Oct 2011 18:48:13 -0000 1.205 +++ Src/exec.c 10 Dec 2011 18:09:26 -0000 @@ -925,7 +925,7 @@ entersubsh(int flags) } } } - } else if (thisjob != -1 && (flags & ESUB_PGRP)) { + } else if (thisjob != -1 && (flags & ESUB_PGRP) && !subsh) { if (jobtab[list_pipe_job].gleader && (list_pipe || list_pipe_child)) { if (setpgrp(0L, jobtab[list_pipe_job].gleader) == -1 || killpg(jobtab[list_pipe_job].gleader, 0) == -1) { -- Peter Stephenson Web page now at http://homepage.ntlworld.com/p.w.stephenson/