From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14811 invoked by alias); 10 Dec 2011 23:28: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: 29995 Received: (qmail 3367 invoked from network); 10 Dec 2011 23:28:10 -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 23:28:01 +0000 From: Peter Stephenson To: zsh-workers@zsh.org Subject: Re: Bug in sh emulation Message-ID: <20111210232801.7dc8fef2@pws-pc.ntlworld.com> In-Reply-To: <20111210194022.5051f91c@pws-pc.ntlworld.com> References: <111209184747.ZM5000@torch.brasslantern.com> <20111210194022.5051f91c@pws-pc.ntlworld.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 (Sorry if you get this twice, but it kind of fits the theme.) On Sat, 10 Dec 2011 19:40:22 +0000 Peter Stephenson wrote: >> emulate -sh '(echo | grep)' > > What's confusing me, possibly based on ignorance, is that I naively > expect something like the following to happen (without my > ultra-ultra-tentative patch). I've examined this a bit further, and got to the point where my brain's stopped working. > - Shell forks. This is treated pretty much like any other fork to > create a new foreground process. > > - Job control is active, so the forked shell takes over the TTY and sets > itself as the group leader. That's the first time through the code > under discussion, in entersubsh() for the case where MONITOR is still > set. > > - Shell forks again. This is a pipeline, so part of the same process > group. I would expect this to find there is already a group leader from > the previous fork, so this process doesn't try to make itself group > leader and grab the pipeline. Evidently this isn't happening, > however. I think what's happening is - We entersubsh() for the initial fork for the subshell. This sets job 1 as group leader and attaches that to the TTY. This is the normal case; what's different at this point is simply that we leave MONITOR set. - We execlist() to run the list for the subshell. - In execpline() we set the job to 2; execpline() always starts a new job. - We get execmd() to start the pipeline. We fork because we're executing the first command of a pipeline. All basically as expected so far. - We entersubsh() again. MONITOR is still set (this is where the difference really kicks in) so we execute the code for handling the tty again. We're now job 2, so no group leader for this. We create a new group leader, and try to attach this to the tty, but we can't because job 1 is attached to it. - Something goes KAPOW! loudly in some moral sense. I suppose the problem is we're doing the attach in the wrong way. Normally we make the parent shell hand over the terminal to the appropriate job (er, right? that's basically what job control is?) In this case we grab it from the subprocess. That blows up when subprocesses themselves are doing job control --- they should be handing it on to their subprocesses. Er... maybe? So what's with the stuff in entersubsh() that we always execute anyway, and successfully does atttachtty() the first time? Should we really have done that in the parent shell? I wonder if this is related to the business with the "superjob" in the case of a non-subshell that I never understood? There's code in handle_sub() in jobs.c line 278 that looks like it might be trying to do something like what we need to do here. Confused of Cambridge -- Peter Stephenson Web page now at http://homepage.ntlworld.com/p.w.stephenson/