From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FROM,MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.2 Received: from primenet.com.au (ns1.primenet.com.au [203.24.36.2]) by inbox.vuxu.org (OpenSMTPD) with ESMTP id 76fddafe for ; Thu, 25 Apr 2019 21:17:59 +0000 (UTC) Received: (qmail 3294 invoked by alias); 25 Apr 2019 21:17:46 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: List-Unsubscribe: X-Seq: 44255 Received: (qmail 2688 invoked by uid 1010); 25 Apr 2019 21:17:45 -0000 X-Qmail-Scanner-Diagnostics: from mail-wm1-f67.google.com by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.101.1/25426. spamassassin: 3.4.2. Clear:RC:0(209.85.128.67):SA:0(-2.2/5.0):. Processed in 2.526595 secs); 25 Apr 2019 21:17:45 -0000 X-Envelope-From: stephane.chazelas@gmail.com X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: pass (ns1.primenet.com.au: SPF record at _netblocks.google.com designates 209.85.128.67 as permitted sender) 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== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state: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=ZpnjvqXiPTJFkGMr3PaiVzSfwDHPJMMKGk4a8NpGsW3WRyLgFSRqqotPpvUAcaWqIN +EJEX1SwP9vyF1M2OZvNpJp+EwYXtoU/+rOVcKSdZGD5ffASoA6l2FeF6KnxbaSRKd99 wv80+uOhOsT8GdcvpZZNeER02QnhTkuylb47plJUXuTBJ+XCf8cSCscOf0+/LvPiaMb+ K+EOi6HtI9KuWCap/C+rW1pCy+BTbi3VObPzvbAwGL54ozif1DMQYVQVsaqfnnp8UnWX 51jGcH6wL6mko3W56YcoEev9yGLJPg5iCoaGZWq7oXRBQvGkAC1BlKLFnLiP8ZIfdtyA ZrJg== X-Gm-Message-State: APjAAAXb44AHieoXy/NveSsLBgVTupuiu/GvIiRhPCyi8Lh4X23lrf5Q IFGP5A7/tp2WV/slA2tdtgA= X-Google-Smtp-Source: APXvYqzMiSIi2dcilCOBo3aJQi8en1Wfa299IDt5+mt52yaPGJoVEeTaddfuhoSz3T0o212LdYPCzQ== X-Received: by 2002:a1c:99d5:: with SMTP id b204mr4826360wme.141.1556227028153; Thu, 25 Apr 2019 14:17:08 -0700 (PDT) Date: Thu, 25 Apr 2019 22:17:04 +0100 From: Stephane Chazelas To: Peter Stephenson Cc: zsh-workers@zsh.org Subject: Re: Why does zsh un-ignores SIGQUIT? Message-ID: <20190425211704.n6urllyyfegcqxe6@chaz.gmail.com> Mail-Followup-To: Peter Stephenson , zsh-workers@zsh.org References: <20190424081314.bijg2xmore4bro2v@chaz.gmail.com> <457ef1932f2d33314f6dee6581f7e496613125e4.camel@ntlworld.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <457ef1932f2d33314f6dee6581f7e496613125e4.camel@ntlworld.com> User-Agent: NeoMutt/20171215 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(). [...patch skipped...] Thanks, that change seems to introduce a new inconsistency though. See below. 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 nuisance today. In zsh trap handler INT Installs the "handler" on SIGINT even if SIGINT was ignored on startup. What I found out recently though (https://unix.stackexchange.com/questions/513781/regain-ability-to-use-c-to-close-backgrounded-then-effectively-foregrounded-p/515159#515159) is that it does seem to honour the POSIX requirement when it comes to "resetting" the signal disposition (to its default). In zsh 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') SigIgn: 0000000000000002 One can work around that by setting a trap first: $ (trap "" INT; zsh -c 'trap : INT; trap - INT; grep SigIgn /proc/self/status') SigIgn: 0000000000000000 Even explicitely ignoring it will do: $ (trap "" INT; zsh -c 'trap "" INT; trap - INT; grep SigIgn /proc/self/status') SigIgn: 0000000000000000 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') SigIgn: 0000000000000002 (with the diff applied) I was able to reset the default handler for SIGQUIT but not for SIGINT. 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 myscript & 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: nohup myscript You want myscript and all the processes it spawns to be immune to hang-ups. 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. cmd & 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 mentioned earlier. 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 come handy. 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? -- Stephane