From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12057 invoked from network); 27 Sep 2003 02:39:05 -0000 Received: from sunsite.dk (130.225.247.90) by ns1.primenet.com.au with SMTP; 27 Sep 2003 02:39:05 -0000 Received: (qmail 13191 invoked by alias); 27 Sep 2003 02:38:58 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 19142 Received: (qmail 20128 invoked from network); 26 Sep 2003 17:38:57 -0000 Received: from localhost (HELO sunsite.dk) (127.0.0.1) by localhost with SMTP; 26 Sep 2003 17:38:57 -0000 X-MessageWall-Score: 0 (sunsite.dk) Received: from [4.64.232.255] by sunsite.dk (MessageWall 1.0.8) with SMTP; 26 Sep 2003 17:38:56 -0000 Received: (from schaefer@localhost) by candle.brasslantern.com (8.11.6/8.11.6) id h8QHcss08283 for zsh-workers@sunsite.dk; Fri, 26 Sep 2003 10:38:54 -0700 From: Bart Schaefer Message-Id: <1030926173854.ZM8282@candle.brasslantern.com> Date: Fri, 26 Sep 2003 17:38:54 +0000 In-Reply-To: <20030926165251.GA14940@clipper.ens.fr> Comments: In reply to Nicolas George "Subshell exiting, suspend problem" (Sep 26, 6:52pm) References: <20030926165251.GA14940@clipper.ens.fr> X-Mailer: Z-Mail (5.0.0 30July97) To: zsh-workers@sunsite.dk Subject: Re: Subshell exiting, suspend problem MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Sep 26, 6:52pm, Nicolas George wrote: } } There seems to be a problem with zsh process group handling: when zsh is } invoked as an interactive subshell from a curses-based program (by } example with :shell from vim, but the same is true with mutt, less, } flrn...), when zsh exits, the calling process gets suspended for "tty } output" (only if it is under job control, or else it makes a read } error). I was concerned that this would happen when Philippe Troin's patch from zsh-workers/18319 was applied, but at the time I couldn't find a concrete example. I've been of the opinion that, except e.g. when zsh is started by (the equivalent of) /bin/login as the first process on a terminal, it should be up to the process that is starting zsh to decide what pgrp zsh goes into, and zsh has no business acquiring anything. The question is whether it's more important to work around buggy "su" implementations, or to have philosophically correct behavior. } [...] release_pgrp() is never called. The following patch } fixes the problem: [...] } But I am not quite sure if this is exactly the right thing: maybe the } correct condition is to call release_pgrp() if and only if } acquire_pgrp() was called. What effect does release_pgrp() have on any jobs started by zsh that are still running in the background? I suspect it would disown them. This is why I think zsh should not have called acquire_pgrp() in the first place -- those background jobs should be in the pgrp of whatever is in control of the terminal after zsh exits, so that they still receive any HUP signals etc. when that parent process finally exits.