From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26207 invoked by alias); 12 Dec 2011 16:06:58 -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: 30011 Received: (qmail 4168 invoked from network); 12 Dec 2011 16:06:56 -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, SPF_HELO_PASS autolearn=ham version=3.3.2 Received-SPF: none (ns1.primenet.com.au: domain at csr.com does not designate permitted sender hosts) Date: Mon, 12 Dec 2011 16:06:17 +0000 From: Peter Stephenson To: Subject: Re: Bug in sh emulation Message-ID: <20111212160617.6ee3026c@pwslap01u.europe.root.pri> In-Reply-To: <111212074417.ZM1511@torch.brasslantern.com> References: <111209184747.ZM5000@torch.brasslantern.com> <20111210194022.5051f91c@pws-pc.ntlworld.com> <20111210232801.7dc8fef2@pws-pc.ntlworld.com> <20111211193949.2d58062b@pws-pc.ntlworld.com> <20111211202024.07c046df@pws-pc.ntlworld.com> <20111211205658.365243c7@pws-pc.ntlworld.com> <111211153918.ZM32739@torch.brasslantern.com> <20111212100100.0696825b@pwslap01u.europe.root.pri> <111212074417.ZM1511@torch.brasslantern.com> Organization: Cambridge Silicon Radio X-Mailer: Claws Mail 3.7.9 (GTK+ 2.22.0; i386-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.101.11.233] X-Scanned-By: MailControl 7.6.5 (www.mailcontrol.com) on 10.71.0.132 On Mon, 12 Dec 2011 07:44:17 -0800 Bart Schaefer wrote: > On Dec 12, 10:01am, Peter Stephenson wrote: > } > } the parent shell just lets the new process (whatever it's doing, just as > } long as it's in the foreground) grab the terminal --- if you search the > } code for attachtty(), and ignore the cases where we attaching to mypgrp, > } the shell's own process group, the only other ones in the parent shell > } are special cases. > > OK, I'm good with that, but are you sure that the correct pgrp is > ending up attached? I was concerned about the subshell pipeline not > receiving tty signals before, but now I'm concerned about signals > not going to the previously-attached group from which the subshell > is taking control. I think this must be OK (unless, of course, something is failing where I don't see it). The chunk of code in entersubsh() we've been staring at is the one that's only executed if there's no group leader, and in that case it creates its own process group and attaches that to the tty immediately. So if that succeeds then by definition it's the process group we're just starting in the foreground. We get this twice (even after the last patch): first the subshell puts itself in the foreground, then the pipeline being run from the subshell puts itself into the foreground. If we weren't doing job control in the subshell, the second one wouldn't happen: the subshell and everything run from it would be treated as a single foreground job (this is the normal case for zsh native mode). -- Peter Stephenson Software Engineer Tel: +44 (0)1223 692070 Cambridge Silicon Radio Limited Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, UK Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom More information can be found at www.csr.com. Follow CSR on Twitter at http://twitter.com/CSR_PLC and read our blog at www.csr.com/blog