From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25612 invoked from network); 26 Oct 2002 03:06:11 -0000 Received: from sunsite.dk (130.225.247.90) by ns1.primenet.com.au with SMTP; 26 Oct 2002 03:06:11 -0000 Received: (qmail 17741 invoked by alias); 26 Oct 2002 03:06:06 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 17860 Received: (qmail 17728 invoked from network); 26 Oct 2002 03:06:05 -0000 To: zsh-workers@sunsite.dk Subject: Re: Bug+patch: zsh fails to set itself as process group leader when running interactively References: <87fzuuaq5h.fsf@ceramic.fifi.org> From: Philippe Troin Date: 25 Oct 2002 20:06:02 -0700 In-Reply-To: <87fzuuaq5h.fsf@ceramic.fifi.org> Message-ID: <87bs5hc31h.fsf@ceramic.fifi.org> User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: Philippe Troin Philippe Troin writes: > Found in 4.0.6 (and earlier). > > If zsh is spawned interactively from another program, it fails to > establish itself as a process group leader, leading to deliveries of > terminal-related signals to both zsh and its parent. Generally the > parent dies, leaving two shells reading from the same terminal. As a follow-up to myself... I've also found in init.c:init_signals() the following piece of code: if (jobbing) { long ttypgrp; while ((ttypgrp = gettygrp()) != -1 && ttypgrp != mypgrp) kill(0, SIGTTIN); if (ttypgrp == -1) { opts[MONITOR] = 0; } else { signal_ignore(SIGTTOU); signal_ignore(SIGTSTP); signal_ignore(SIGTTIN); attachtty(mypgrp); } } It's probably unnecessary and duplicate code in init_io() and should be replaced by: if (jobbing) { signal_ignore(SIGTTOU); signal_ignore(SIGTSTP); signal_ignore(SIGTTIN); } Phil.