Zsh Mailing List Archive
Messages sorted by:
Re: Subshell exiting, suspend problem
- X-seq: zsh-workers 19144
- From: Philippe Troin <phil@xxxxxxxx>
- To: Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>
- Subject: Re: Subshell exiting, suspend problem
- Date: 26 Sep 2003 20:21:53 -0700
- Cc: zsh-workers@xxxxxxxxxx
- In-reply-to: <1030926173854.ZM8282@xxxxxxxxxxxxxxxxxxxxxxx>
- Mail-copies-to: nobody
- Mailing-list: contact zsh-workers-help@xxxxxxxxxx; run by ezmlm
- References: <20030926165251.GA14940@xxxxxxxxxxxxxx> <1030926173854.ZM8282@xxxxxxxxxxxxxxxxxxxxxxx>
- Sender: 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
> } [...] 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
- 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
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
> 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
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?
Messages sorted by: