Re: Subshell exiting, suspend problem

[Bart Schaefer <schaefer@brasslantern.com>]

On Sep 26,  8:21pm, Philippe Troin wrote:
}
} AFAIR, SIGHUP only gets sent to all members of a session when the
} session leader exits. It is not related to process groups.

It depends on the antiquity of your operating system, actually.  There
is AFAIK no distinction between sessions and process groups in some
versions of unix (i.e., a session is a process group that has a TTY).
I forget when setsid() et al. were introduced, but it is not universal
to all OSs on which zsh compiles.

} So acquire/release_pgrp() are irrelevant in this instance since these
} background jobs are part of the same session.

That may be true for the HUP on session leader exit, but what about e.g.
TSTP when the user types ^Z, or INT on ^C ?

E.g. if bash starts mutt which starts zsh which starts vi, and then the
user types ^Z, I believe it should be up to mutt to have placed zsh in
its own process group if mutt did not want the TSTP.  In this case I
don't think zsh has any business forcing itself to be the group leader,
even if it is interactive.

However, there are enough programs that don't pay attention to this
detail when spawning a child process that it may be preferable for zsh
to ignore this philosophical nicety, especially when job control is
enabled.

} How is the situation you describe different from (say) a subshell
} spawned from zsh directly?

Depends what you mean by a "subshell" -- I prefer to restrict that term
to the shell syntactic construct of placing a command in parens, not to
explicitly starting a new shell by name from the prompt of another.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net