From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10409 invoked from network); 27 Sep 2003 03:22:08 -0000 Received: from sunsite.dk (130.225.247.90) by ns1.primenet.com.au with SMTP; 27 Sep 2003 03:22:08 -0000 Received: (qmail 27604 invoked by alias); 27 Sep 2003 03:21:57 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 19144 Received: (qmail 27592 invoked from network); 27 Sep 2003 03:21:57 -0000 Received: from localhost (HELO sunsite.dk) (127.0.0.1) by localhost with SMTP; 27 Sep 2003 03:21:57 -0000 X-MessageWall-Score: 0 (sunsite.dk) Received: from [216.27.190.146] by sunsite.dk (MessageWall 1.0.8) with SMTP; 27 Sep 2003 3:21:56 -0000 Received: from ceramic.fifi.org (mail@ceramic.fifi.org [216.27.190.147]) by tantale.fifi.org (8.9.3p2/8.9.3/Debian 8.9.3-21) with ESMTP id UAA10282; Fri, 26 Sep 2003 20:21:54 -0700 Received: from phil by ceramic.fifi.org with local (Exim 4.22) id 1A35eb-0003ri-Q3; Fri, 26 Sep 2003 20:21:53 -0700 To: Bart Schaefer Cc: zsh-workers@sunsite.dk Subject: Re: Subshell exiting, suspend problem References: <20030926165251.GA14940@clipper.ens.fr> <1030926173854.ZM8282@candle.brasslantern.com> Mail-Copies-To: nobody From: Philippe Troin Date: 26 Sep 2003 20:21:53 -0700 In-Reply-To: <1030926173854.ZM8282@candle.brasslantern.com> Message-ID: <87fziiq5ke.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 Bart Schaefer writes: > 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. The patch does much more than work around buggy su's :-) It also makes job control work when zsh is spawned by an non-shell, non-login program. > } [...] 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. I don't get it. Release_pgrp() only ought to be called when zsh terminates one way or the other. The current code calls (acquire|release)_pgrp(): - on startup, acquire_pgrp is called. - upon exec, release_pgrp is called - upon suspend release_pgrp is called, and when zsh is resumed acquire_pgrp is called again. - when clone is called (mostly irrelevant for the present discussion) I forgot (blame me): - call release_pgrp() on exit, hence the bug. As far as calling release_pgrp() with jobs in the background: - when suspend is called from a zsh which has processes in the background: for the backgrounded processes, it is strictly equivalent to zsh putting another job in the foreground. - the only other case where release_pgrp() is called is upon exit (at least after this patch has been applied), and the jobs will continue, orphaned... > 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. AFAIR, SIGHUP only gets sent to all members of a session when the session leader exits. It is not related to process groups. So acquire/release_pgrp() are irrelevant in this instance since these background jobs are part of the same session. How is the situation you describe different from (say) a subshell spawned from zsh directly? Phil.