Re: Subshell exiting, suspend problem

[Bart Schaefer <schaefer@brasslantern.com>]

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.