From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28497 invoked by alias); 25 Aug 2013 00:02:10 -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: 31664 Received: (qmail 14469 invoked from network); 25 Aug 2013 00:01:54 -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 Received-SPF: none (ns1.primenet.com.au: domain at closedmail.com does not designate permitted sender hosts) From: Bart Schaefer Message-id: <130824170157.ZM15713@torch.brasslantern.com> Date: Sat, 24 Aug 2013 17:01:57 -0700 In-reply-to: <20130824224839.5830e7fd@pws-pc.ntlworld.com> Comments: In reply to Peter Stephenson "Re: zpty non-functional?" (Aug 24, 10:48pm) References: <20130824124422.GA14766@mugenguild.com> <130824131041.ZM15573@torch.brasslantern.com> <20130824224839.5830e7fd@pws-pc.ntlworld.com> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: zsh-workers@zsh.org Subject: Re: zpty non-functional? MIME-version: 1.0 Content-type: text/plain; charset=us-ascii On Aug 24, 10:48pm, Peter Stephenson wrote: } } Hmm... this is well outside my comfort zone. I thought the following } existing code: } } #ifdef TIOCSCTTY } ioctl(slave, TIOCSCTTY, 0); } #endif } } TIOCSCTTY int arg } Make the given terminal the controlling terminal of the calling } process. } } But it apparently doesn't It makes the terminal the controlling terminal, but it doesn't make the process the group leader for that terminal. I suspect we also need the ioctl(slave, TIOCSPGRP, mypid); [or equivalent, e.g. tcsetpgrp()] that attachtty() is doing. I'm a bit surprised that calling attachtty() works, because it relies on SHTTY having been set to the right thing, and I don't see that anything in zpty.c is making sure that slave and SHTTY refer to the same fd; but perhaps it always is for some indirect reason ... Is it safe/reasonable to add SHTTY = slave; right before the attachtty() call in your patch? } The following is after the setsid() (or setpgrp() if that fails or } doesn't exist). Maybe it should be conditional on one of those } succeeding (and do we *really* want to do setpgrp() if setsid() fails, } even with a warning)? Or maybe I'm missing the point entirely and just } got lucky? The manual page for setsid says: The only error which can happen is EPERM. It is returned when the process group ID of any process equals the PID of the calling process. Thus, in particular, setsid fails if the calling process is already a process group leader. A check of the setpgrp() manual page indicates pretty much the same thing; there is no defined error that can result from setprp(0L, getpid()); the only errors are from attempting to set the process group of a different process than the caller. So only some completely unexpected error (interrupted system call?) could cause setsid() to fail, in which case trying again with setpgrp() is no worse off.