From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13760 invoked by alias); 10 Dec 2011 19:40:41 -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: 29986 Received: (qmail 17380 invoked from network); 10 Dec 2011 19:40:30 -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 19:40:22 +0000 From: Peter Stephenson To: zsh-workers@zsh.org Subject: Re: Bug in sh emulation Message-ID: <20111210194022.5051f91c@pws-pc.ntlworld.com> In-Reply-To: <111209184747.ZM5000@torch.brasslantern.com> References: <111209184747.ZM5000@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 18:47:47 -0800 Bart Schaefer wrote: > 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). While my minds on this, and in the knowledge that, based on past form, only Bart is actually going to respond... 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). - Shell forks. This is treated pretty much like any other fork to create a new foreground process. If, for example, it was an editor we'd expect the parent shell to stand back and let the editor grab the terminal. I don't see anything that makes the subshell a special case here. For example, we call addproc() to mark the newly forked process as the group leader from the main shell. - 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. (Have I got this wrong? Is there actually some difference that means the subshell, unlike any other foreground process, can't take over the terminal? If so, where is the logic for that? Yet apparently the *first* fork is happy --- it's only where we've got the pipeline with two forks that it hangs.) - 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. So what have I got wrong? It could be anything, e.g. something in the newly created subshell thinks it needs to create a new job, so the next part of the pipeline doesn't know it's part of the same process group. I'm pretty lost here. -- Peter Stephenson Web page now at http://homepage.ntlworld.com/p.w.stephenson/