Re: Subshell exiting, suspend problem

[Philippe Troin <phil@xxxxxxxx>]

Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> 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.