Re: Subshell exiting, suspend problem

[Philippe Troin <phil@fifi.org>]

Nicolas George <nicolas.george@ens.fr> 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.