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 7684880d for ; Mon, 16 Dec 2019 06:38:49 +0000 (UTC) Received: (qmail 5152 invoked by alias); 16 Dec 2019 06:38:42 -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: 45046 Received: (qmail 29685 invoked by uid 1010); 16 Dec 2019 06:38:42 -0000 X-Qmail-Scanner-Diagnostics: from mail-lj1-f172.google.com 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(209.85.208.172):SA:0(-1.9/5.0):. Processed in 2.155132 secs); 16 Dec 2019 06:38:42 -0000 X-Envelope-From: schaefer@brasslantern.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.208.172 as permitted sender) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=U2u8S3kwdsqZpPtcLv1QcTxnZyrk2DHF7alAyS0QbjY=; b=Fpfuvw/KB68yjECT39uXuDGwe0czOlk9kZ25d34RnsMy/5tY56TjE1WM8mzBBDDs9t Z1Nv6VIawrkiTc+aIiXT395mA4z7//f9lSM1d8a/WMLkC1F7+W0pv+fno/XvfhpSoEq+ 0LpIarQerTTy7SEAruZxA4sw8gJH7j/4fsmHNjR3+ttwwVxn7BsRBDZ9jT/g2Zt28t0J QpqVNKyW/mFVWUl4GVjp31nf+ARYFCQ5Te2Fb1/h6VkvaOCLumNrH9BeVSuSaelzgphD PdmcwZ48/Bf4YXPwRmLSF4ghenrSBFbkbofggCjjfhkm2thDO4rBmSWE/a/BV6n729mp eiJw== X-Gm-Message-State: APjAAAXebm6v4DrvvpodmuGR5NDy+E1Iisp/ybolG9pL+4vX1B5gtO2x omtYckrEKmxzT5Emor7taRCx3DTV0s8fZtqiPCsq0g== X-Google-Smtp-Source: APXvYqzU7Bn3VT/L5an5tzYA+qoaRMGu1nVVwcU0VTPIbzuDCqWsXK9lPIu+cx71E9kWyKbk4xVdpvfRWNNwNI4JAi4= X-Received: by 2002:a2e:8698:: with SMTP id l24mr18793602lji.94.1576478285633; Sun, 15 Dec 2019 22:38:05 -0800 (PST) MIME-Version: 1.0 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> <20191216052423.svgnhfkpsxh46a6j@tarpaulin.shahaf.local2> In-Reply-To: <20191216052423.svgnhfkpsxh46a6j@tarpaulin.shahaf.local2> From: Bart Schaefer Date: Sun, 15 Dec 2019 22:37:53 -0800 Message-ID: Subject: Re: Bug with traps and exit To: Daniel Shahaf Cc: Peter Stephenson , "zsh-workers@zsh.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, Dec 15, 2019 at 9:25 PM Daniel Shahaf wrot= e: > > workers/44007 (also in this thread): > > > trap 'printf $1; exit; printf $2' USR1 > > fn() { > > printf 1 > > kill -s usr1 $$ > > printf 2 > > } > > printf 0 > > fn A B > > printf 3 > > Here, Martijn was saying that zsh should print 01A but in fact prints 01A= 2. Have a look at the "shell_exiting" global manipulated in builtin.c. (Some comments still refer to "in_exit" which IIRC was replaced by "shell_exiting".) > This suggests the 'exit' inhibits =C2=ABprintf $2=C2=BB and =C2=ABprintf = 3=C2=BB from running, but > doesn't inhibit =C2=ABprintf 2=C2=BB (without a dollar sign) from running= . How would > you approach something like this? I'm guessing bin_exit should set a glo= bal > volatile int variable to '1' if it's called from a signal handler, but wh= ere > would that variable be checked? Note that "from_where" in zexit() already indicates whether we are coming from a signal, but bin_break (which handles BIN_EXIT) does not treat "in a signal handler" as "coming from a signal" when calling zexit(). This is why the function continues running -- zexit() passes from_where =3D 2 ("can't actually exit yet"), I suspect in order to allow running an EXIT trap set by the function itself. The trouble is that we also have to treat differently the cases of the trap having been set inside the function, and the trap existing outside the function when the function is called. Trivially treating exit from a handler the same as being killed by signal whose default behavior is to exit, leads to failures in the test suite.