From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23472 invoked from network); 26 Sep 2003 18:32:56 -0000 Received: from sunsite.dk (130.225.247.90) by ns1.primenet.com.au with SMTP; 26 Sep 2003 18:32:56 -0000 Received: (qmail 16369 invoked by alias); 26 Sep 2003 18:32:49 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 19141 Received: (qmail 16358 invoked from network); 26 Sep 2003 18:32:48 -0000 Received: from localhost (HELO sunsite.dk) (127.0.0.1) by localhost with SMTP; 26 Sep 2003 18:32:48 -0000 X-MessageWall-Score: 0 (sunsite.dk) Received: from [216.27.190.146] by sunsite.dk (MessageWall 1.0.8) with SMTP; 26 Sep 2003 18:32:48 -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 LAA21098; Fri, 26 Sep 2003 11:32:44 -0700 Received: from phil by ceramic.fifi.org with local (Exim 3.35 #1 (Debian)) id 1A2xOV-00024z-00; Fri, 26 Sep 2003 11:32:43 -0700 To: Nicolas George Cc: zsh-workers@sunsite.dk Subject: Re: Subshell exiting, suspend problem References: <20030926165251.GA14940@clipper.ens.fr> Mail-Copies-To: nobody From: Philippe Troin Date: 26 Sep 2003 11:32:43 -0700 Message-ID: <873cejqu2c.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 Nicolas George writes: > 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). True indeed. > The problem arises with zsh 4.1.1, or with a CVS snapshot from half an > hour ago, and also with the Debian-patched 4.0.7. > > I have tracked the problem, and it seems that acquire_pgrp() is called > from init_io(), but release_pgrp() is never called. The following patch > fixes the problem: > > > --- Src/builtin.c 2003-09-26 16:16:45.000000000 +0200 > +++ Src/builtin.c.orig 2003-09-26 16:16:09.000000000 +0200 > @@ -3977,9 +3977,6 @@ > if (sigtrapped[SIGEXIT]) > dotrap(SIGEXIT); > runhookdef(EXITHOOK, NULL); > - if (opts[MONITOR] && interact && (SHTTY != -1)) { > - release_pgrp(); > - } > if (mypid != getpid()) > _exit(val); > else Your patch seems to be reversed. > 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. The only thing I am sure is that something > like that is necessary. No, you're right, release_pgrp() ought to be called upon exit. Good catch. I am going to run some extra tests before confirming this patch. I'm also not sure we need all the extra tests (opts[MONITOR], etc). Phil.