Zsh Mailing List Archive
Messages sorted by:
Re: Why does zsh un-ignores SIGQUIT?
- X-seq: zsh-workers 44255
- From: Stephane Chazelas <stephane.chazelas@xxxxxxxxx>
- To: Peter Stephenson <p.w.stephenson@xxxxxxxxxxxx>
- Subject: Re: Why does zsh un-ignores SIGQUIT?
- Date: Thu, 25 Apr 2019 22:17:04 +0100
- Cc: zsh-workers@xxxxxxx
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-disposition:in-reply-to:user-agent; bh=WU/yT8V3HUuOWFBW0Nn2SdKidOot6/jx0vgahjIEn5o=; b=fwPnOG9bg1iNXJcv+PVS/6i+mCo+D+/yGLuzsMkefTvDdZz2WwGuEcjF2uqQg6ycX8 9ftqGQjDW1OfvSe2YlbLyr2gMhoiJcOJ+derbGzdGdxJnBtUjP8IyHd5pz8v3ciIqsTX ZrMGGm1nhF4uoByOchZeom1vkkRN7gquj7BYxXeA5duu2N6biPlZfvqWkicozsgEimAr MSYZPMlqT/GxFG0oaBOZ6SBeogjD5lNwQ6lBaGOJbVnfVAdLT0p96abj/1ScrF/eDcuy L7kZCPPC9NxAh9xFNkSjDwYcWwBrGkHIf29Y1Y/VdfK1OYMBIpZq3ApWiLGUVAXQSyLh sOFQ==
- In-reply-to: <firstname.lastname@example.org>
- List-help: <mailto:email@example.com>
- List-id: Zsh Workers List <zsh-workers.zsh.org>
- List-post: <mailto:firstname.lastname@example.org>
- List-unsubscribe: <mailto:email@example.com>
- Mail-followup-to: Peter Stephenson <p.w.stephenson@xxxxxxxxxxxx>, zsh-workers@xxxxxxx
- Mailing-list: contact zsh-workers-help@xxxxxxx; run by ezmlm
- References: <firstname.lastname@example.org> <email@example.com>
2019-04-24 17:13:51 +0100, Peter Stephenson:
> On Wed, 2019-04-24 at 09:13 +0100, Stephane Chazelas wrote:
> > $ (trap '' QUIT; grep SigIgn /proc/self/status; ./Src/zsh -c 'grep SigIgn /proc/self/status')
> > SigIgn: 0000000000000004
> > SigIgn: 0000000000000000
> > That only seems to be happening for SIGQUIT.
> > (that's from the current git HEAD)
> SIGQUIT is ignored internally within the shell, visible below the patched
> code. The shell knows if you've explicitly ignored SIGQUIT, but not if
> it's ignored by inheritance when the shell starts. The flag is tested
> in entersubsh().
that change seems to introduce a new inconsistency though. See
POSIX does require that signals that were ignored upon startup
of the shell remain ignored.
POSIX> Signals that were ignored on entry to a non-interactive
POSIX> shell cannot be trapped or reset, although no error need
POSIX> be reported when attempting to do so. An interactive
POSIX> shell may reset or catch signals ignored on entry.
zsh, thankfully ignores that requirement. That's an annoying
requirement that probably has its origin on systems that didn't
have terminal job control (tcsetpgrp()...) and is usually a
trap handler INT
Installs the "handler" on SIGINT even if SIGINT was ignored on
What I found out recently though
is that it does seem to honour the POSIX requirement when it
comes to "resetting" the signal disposition (to its default).
trap - INT
Does not reset the default signal disposition of SIGINT if
SIGINT was ignored upon startup.
$ (trap "" INT; zsh -c 'trap - INT; grep SigIgn /proc/self/status')
One can work around that by setting a trap first:
$ (trap "" INT; zsh -c 'trap : INT; trap - INT; grep SigIgn /proc/self/status')
Even explicitely ignoring it will do:
$ (trap "" INT; zsh -c 'trap "" INT; trap - INT; grep SigIgn /proc/self/status')
Which brings us to this change, which means SIGQUIT is now
treated specially in this regard:
$ (trap "" INT QUIT; ./Src/zsh -c 'trap - INT QUIT; grep SigIgn /proc/self/status')
(with the diff applied)
I was able to reset the default handler for SIGQUIT but not for
I wonder what the rationale is for why zsh will happily install a
handler on an ignored signal but not reset to default.
I can understand where the POSIX requirement is coming from.
When you do
on a system that doesn't have job control, you don't want
processes started by the script to be killed when you press ^C.
Or when you do:
You want myscript and all the processes it spawns to be immune
But I don't understand why zsh would let me set a handler but
not reset to default. It would make more sense to me if it was the
reverse. If I want to reset the default handler without having
set one in the first place, surely I know what I'm doing and
what I ask should be honoured.
Here, unless someone can think of a good reason why zsh behaves
the way it does, I'd suggest zsh ignore the POSIX requirement
altogether and honours what the user wants: apply the traps as
requested regardless of whether the signal was ignored on
startup or not, at least in zsh emulation.
Maybe honour the POSIX requirements in sh emulation.
While I'm at it, there's another related POSIX requirement that
I often find annoying:
In non-interactive shells.
is meant to run cmd with SIGINT and SIGQUIT ignored (some form
of crude and ancient uncalled for job control).
That's actually more annoying than the other POSIX requirement
When you do:
(cmd1 & cmd2) | cmd3
There's no reason cmd1 should not also be killed by SIGINT when
you press ^C.
That's where being able to cancel that ignoring of SIGINT can
zsh does honour that latter requirement though.
What's the sentiment of zsh developer about potentially ignoring
that POSIX requirement as well? What can that break?
Messages sorted by: