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.0 required=5.0 tests=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 e588a7d4 for ; Sun, 15 Dec 2019 21:10:16 +0000 (UTC) Received: (qmail 29878 invoked by alias); 15 Dec 2019 18:59:57 -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: 45037 Received: (qmail 11590 invoked by uid 1010); 15 Dec 2019 18:59:57 -0000 X-Qmail-Scanner-Diagnostics: from know-smtprelay-omc-8.server.virginmedia.net by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.102.1/25663. spamassassin: 3.4.2. Clear:RC:0(80.0.253.72):SA:0(-2.0/5.0):. Processed in 0.724324 secs); 15 Dec 2019 18:59:57 -0000 X-Envelope-From: p.w.stephenson@ntlworld.com X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: pass (ns1.primenet.com.au: SPF record at _smtprelay.virginmedia.com designates 80.0.253.72 as permitted sender) X-Originating-IP: [86.16.88.158] X-Authenticated-User: p.w.stephenson@ntlworld.com X-Spam: 0 X-Authority: v=2.3 cv=Te64SyYh c=1 sm=1 tr=0 a=MiHCjVqLJ44lE3bxSlffFQ==:117 a=MiHCjVqLJ44lE3bxSlffFQ==:17 a=jpOVt7BSZ2e4Z31A5e1TngXxSK0=:19 a=IkcTkHD0fZMA:10 a=IMQOEtzf5aWU1bTHBaMA:9 a=QEXdDO2ut3YA:10 Message-ID: Subject: Re: Bug with traps and exit From: Peter Stephenson To: zsh-workers@zsh.org Date: Sun, 15 Dec 2019 18:59:21 +0000 In-Reply-To: <20191214112826.4klmtvxvuhioddcf@tarpaulin.shahaf.local2> References: <3859b4bf-08ba-62d5-f00a-3ec4e67caf95@inlv.org> <1576145690.8441.3.camel@samsung.com> <46f2fc10-2f2c-88f1-e4e2-87196a39a37a@inlv.org> <1576248580.5214.17.camel@samsung.com> <20191214112826.4klmtvxvuhioddcf@tarpaulin.shahaf.local2> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.5-0ubuntu0.18.04.1 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-CMAE-Envelope: MS4wfFOI+dkP9xD1l7kv/2ZwBL2eQ7rbh0L4LnvPKzaiDIUmz/TEfLTfRBbIuV7Qbz/leGytY/E9Bgt2umuLbYo9StIkaYMQkeeXZ/EC34owCH8RA6xjS8mr ERbXXVJBRzEt8Do46+QVslv3DKkeP3uaOGN7GwJwmFyBlVxgOZS1o3BG On Sat, 2019-12-14 at 11:28 +0000, Daniel Shahaf wrote: > Peter Stephenson wrote on Fri, Dec 13, 2019 at 14:49:40 +0000: > > As you know, getting anyone interested in looking at things is very > > difficult. I'm taking more of a back seat myself, unless I can see > > something glaring. Anyone is more than welcome to jump in while > > the old guard is still looking on to help. > > I don't know about others, but I'm not even sure where to begin fixing this. > I can find the code handling traps easily enough ('intrap', etc), and I know > where the code handling functions is (doshfunc()), but how to proceed? Would > the right fix be to add some code in the end of runshfunc(), after > unqueue_signals(), that checks whether a trap has been executed and called > 'exit'…? OK, so this is deliberately somewhat wordier than if I was just replying to the message myself, to try to get my thinking across. So please bear with me. Frankly, I'm never sure where to begin fixing *anything* that's not immediately obvious. The first step in something like this is to identify key points where things need to happen and may or may not actually be happening, and then work out whether we're hitting those points, and if not, why not, and if so, why it's doing something different there from what it should (which may include setting something up differently for a future action, in this case on signal delivery). > trap 'echo SIGINT; trap - INT; kill -s INT $$; echo woops' INT > kill -s INT $$ > > zsh prints 'woops', but shouldn't. Martijn is presumably saying the trap - INT within the trap should reset it so the interrupt stops the rest of the trap being dlievered. So does it reset it? Actually, there's some important information below so you probably don't need to, but what you'd have to do is trace through to see what's happening on the "trap - INT" on the trap by getting the shell to stop when it executes the trap command in the signal caught by the kill. The trap is set by the bin_trap() handler; zhandler() is called if the shell is handling an interrupt, though not if the interrupt is set up to kill or suspend the shell or whatever. One easy and obvious thing to try is to simplify: trap - INT; kill -S INT $$; echo foo That doesn't echo "foo"; that's because the INT is delivered immedately. The shell doesn't exit if it's interactive, but we do get returned immediately to the command line. In fact, to shortcut the investigation, I think the key point here is to note that the trap is executed inside the signal handler (see the other recent thread on signal handlers). So we'd expect the "kill -s INT" inside the trap to be delivered after the first trap has exited. So that's probably why you get "whoops". So is that really a problem? You'll have to disucss that with Martijn. Obviously that's not going to change fundamentally without a complete rewrite, and this looks to me a rather silly experiment anywawy --- it looks to me like it's abusing the mechanism to reissue a signal within something designed to handle the signal and then expect that to do something within that same handler --- but I don't want to have to go on deciding all this by myself, so feel free to disagree and discuss further. pws