From: Philippe Troin <phil@fifi.org>
To: Bart Schaefer <schaefer@brasslantern.com>
Cc: zsh-workers@sunsite.dk
Subject: Re: Subshell exiting, suspend problem
Date: 26 Sep 2003 20:21:53 -0700 [thread overview]
Message-ID: <87fziiq5ke.fsf@ceramic.fifi.org> (raw)
In-Reply-To: <1030926173854.ZM8282@candle.brasslantern.com>
Bart Schaefer <schaefer@brasslantern.com> 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.
next prev parent reply other threads:[~2003-09-27 3:22 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-09-26 16:52 Nicolas George
2003-09-26 17:38 ` Bart Schaefer
2003-09-27 3:21 ` Philippe Troin [this message]
2003-09-27 21:00 ` Bart Schaefer
2003-09-26 18:32 ` Philippe Troin
2003-10-03 20:58 ` [19140] " Danek Duvall
2003-10-03 22:06 ` Philippe Troin
2003-10-03 22:24 ` Danek Duvall
2003-10-08 7:04 ` Danek Duvall
2003-10-08 7:26 ` Philippe Troin
2003-10-17 16:54 ` Philippe Troin
2003-10-21 7:30 ` Danek Duvall
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87fziiq5ke.fsf@ceramic.fifi.org \
--to=phil@fifi.org \
--cc=schaefer@brasslantern.com \
--cc=zsh-workers@sunsite.dk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).