From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.3 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,T_SCC_BODY_TEXT_LINE, UNPARSEABLE_RELAY autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 27872 invoked from network); 14 Apr 2022 05:57:48 -0000 Received: from zero.zsh.org (2a02:898:31:0:48:4558:7a:7368) by inbox.vuxu.org with ESMTPUTF8; 14 Apr 2022 05:57:48 -0000 ARC-Seal: i=1; cv=none; a=rsa-sha256; d=zsh.org; s=rsa-20210803; t=1649915868; b=WhzKFDS5Aer71Sa4794wLMxV9xoQkDzTBRm0+gezVFqwPztY+QNPiCC1QWXqIJ1w7EZjtMIzIp wToRmIUYljyNgepuwytJxi1vIySf6sShun9T+pRSsmpFB6hUQhHzRnOOfpdO61x0MT7zvxXllW BSipHERlPng9zo65sL1Ud86693dMO4KwbhvNWyMt5HbEgySXlmd4KfwgCwUuejC99Uc0HSn0uT kXAytfXPTZKHby3r8oTQAeH6BmLEEqxJq/tQdk9Yb59XRf9to+Z/fLDd2kn36nQ3GOxh8sT7ag UyFXjIEWuL/GhrptP0ROt0pa/p4Ki6caxOhYaBNzs+ZtFQ==; ARC-Authentication-Results: i=1; zsh.org; iprev=pass (so254-31.mailgun.net) smtp.remote-ip=198.61.254.31; dkim=pass header.d=klanderman.net header.s=mg header.a=rsa-sha256; dmarc=none header.from=klanderman.net; arc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed; d=zsh.org; s=rsa-20210803; t=1649915868; bh=5kKEWNnT5MXyXqOmVINOpGWFCfrWH71NeNnXoQPul4w=; h=List-Archive:List-Owner:List-Post:List-Unsubscribe:List-Subscribe:List-Help: List-Id:Sender:Content-Type:MIME-Version:References:Message-ID:In-Reply-To: Date:Reply-To:Subject:To:From:DKIM-Signature:DKIM-Signature; b=MigxLUjC+8E9oK4E5Bd56uQwKfcUZgM3KjM6HcSOw2ixkC4XFrH9wuvZF6twI384/Skr0xcdNe I6roQ0ZVNYyRipCBVD4YJOfrGOdquf5LKfNXzAH71ab35M40PGmmEGFF1RDgiYx9BwwR7nouIl X4+uUTjszePEZsk2Ba8MjMRbRfXlyRBgerYif3egfRNsF5PPnsP8LDDyQwhDqolAAovXIX+Gvg /6fS+gQ06oLogmCgBVV38hUoUcY4qGci5VkwRHjFAtjjjatENeMSGC56kIz4YibrDt/nsgudPR 4yXi2pkuXGP1kam7ev2p95NVckAtRM6YBEGiHauB3XTTvA==; DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=zsh.org; s=rsa-20210803; h=List-Archive:List-Owner:List-Post:List-Unsubscribe: List-Subscribe:List-Help:List-Id:Sender:Content-Type:MIME-Version:References: Message-ID:In-Reply-To:Date:Reply-To:Subject:To:From:Cc: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID; bh=HBw/1hoJyi3qA57LvwCudtiKYiYf9GbpwKisvua7cxw=; b=rJu2swzJw9U48VCiax3Cqzr9fx 4NUXZHLaWDz8qGMsPqD3n2PM5WL6rVRoSEGVTfvSfvI7qpHDwk63L1tpepI/fUfYSLWVWqRU/+2/r I+43Bqb9DilDs0NQEHNpn5/rhBzXkAL2bhHYzXtyVoMJdKmijsxWGF+MnX0CsP+ahz9Mtm/4KdV3y VDx9go300KDcsGsvCHiXOtpusFihaVpX860ERGw64h4VYKnseQMqvuaoc06b6uyiFp4dBfWQOAhVJ 7uXSQXVSXXlBebItG619f9OWprjG9bx5O0Fq1LmqkPBhDp3nVNOfnn1llrm1P5yQJLE19OpIFMDXC 0JnlJ6uA==; Received: from authenticated user by zero.zsh.org with local id 1nesUF-000Mpm-3d; Thu, 14 Apr 2022 05:57:47 +0000 Authentication-Results: zsh.org; iprev=pass (so254-31.mailgun.net) smtp.remote-ip=198.61.254.31; dkim=pass header.d=klanderman.net header.s=mg header.a=rsa-sha256; dmarc=none header.from=klanderman.net; arc=none Received: from so254-31.mailgun.net ([198.61.254.31]:10470) by zero.zsh.org with utf8esmtps (TLS1.3:TLS_AES_128_GCM_SHA256:128) id 1nesTy-000MUu-2c; Thu, 14 Apr 2022 05:57:30 +0000 DKIM-Signature: a=rsa-sha256; v=1; c=relaxed/relaxed; d=klanderman.net; q=dns/txt; s=mg; t=1649915849; h=Content-Type: MIME-Version: References: Message-ID: In-Reply-To: Date: Reply-To: Subject: Subject: To: To: From: From: Sender: Sender; bh=HBw/1hoJyi3qA57LvwCudtiKYiYf9GbpwKisvua7cxw=; b=MO6mY9UNv5uRnbYMePzY42rkStKMj3JbUB6XwAMQl5vLuuTvuIkbWc/8o+nMqY6d944c0DkX tI4VdtEwGBnFTn3rXyO+Db283htOw16CjEhS23dinnfX9wNvoHytzKmeUgX8qWckpmA9Pjhk B2gFX1PB+d2bW0D8JrS6vZ1Lczc= X-Mailgun-Sending-Ip: 198.61.254.31 X-Mailgun-Sid: WyIwZjNkNyIsICJ6c2gtd29ya2Vyc0B6c2gub3JnIiwgIjk3ZGJkOCJd Received: from smtp2.klanderman.net (smtp2.klanderman.net [142.93.10.110]) by smtp-out-n03.prod.us-west-2.postgun.com with SMTP id 6257b7c81f77778b070c3172 (version=TLS1.3, cipher=TLS_AES_128_GCM_SHA256); Thu, 14 Apr 2022 05:57:28 GMT Received: from lwm.klanderman.net (pool-72-93-77-73.bstnma.fios.verizon.net [72.93.77.73]) by smtp2.klanderman.net (Postfix) with ESMTPSA id 6EDC440CE8; Thu, 14 Apr 2022 01:57:27 -0400 (EDT) Received: by lwm.klanderman.net (Postfix, from userid 1000) id 58E6B29E00A7; Thu, 14 Apr 2022 01:57:27 -0400 (EDT) From: Greg Klanderman To: zsh-workers@zsh.org Subject: Re: using trap function to cleanup and exit? Reply-To: Greg Klanderman Date: Thu, 14 Apr 2022 01:57:27 -0400 In-Reply-To: (Bart Schaefer's message of "Sun, 10 Apr 2022 13:49:17 -0700") Message-ID: <871qy0yzp4.fsf@lwm.klanderman.net> User-Agent: Gnus/5.1008 (Gnus v5.10.8) XEmacs/21.4.24 (linux) References: <25170.64465.301441.247673@lwm.klanderman.net> <87fsmk2a03.fsf@lwm.klanderman.net> <87czho2967.fsf@lwm.klanderman.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Seq: 50061 Archived-At: X-Loop: zsh-workers@zsh.org Errors-To: zsh-workers-owner@zsh.org Precedence: list Precedence: bulk Sender: zsh-workers-request@zsh.org X-no-archive: yes List-Id: List-Help: List-Subscribe: List-Unsubscribe: List-Post: List-Owner: List-Archive: Hi Bart, thank you for your reply and sorry for the delay getting back to you. I haven't had enough time to fully explore this yet, and won't for at least another week. Some replies inline.. >>>>> On April 10, 2022 Bart Schaefer wrote: > On Sun, Apr 10, 2022 at 9:30 AM Greg Klanderman wrote: >> >> I've tried both exit and return in a list trap, and am not seeing the >> script exit. > The rules for traps and child processes are a bit hard to follow. If > a signal trap is set to something other than the default in the > parent, then that signal is supposed to be blocked in the child, which > means the signal won't be propagated from the parent to the child. > The following options also control signaling behavior: > MONITOR - off by default in scripts, and when off, causes background > jobs to be left running when the shell exits. Right, I expect background processes to be left running by default. > POSIX_JOBS - off by default in native mode, when on forces MONITOR off > in subshells > HUP - on by default, and if MONITOR is also set, causes child > processes to be sent a SIGHUP when the parent exits > TRAPS_ASYNC - off by default, when on the parent handles signals > immediately, otherwise foreground children must exit first This TRAPS_ASYNC default seems to reflect what the page Larry linked to described for bash. The script I posted is using /bin/zsh -f, so TRAPS_ASYNC should be off, but I do see a trap run immediately, when the script is running | at the time the signal is received. Is the considered a foreground child? > POSIX_TRAPS - off in native mode, modifies the behavior of the EXIT > trap (on in sh/bash/ksh emulations) > LOCAL_TRAPS - off in native mode, saves trap state on function entry > and restores on function return >> Also, is exit intentionally disabled from within a trap function? > No; there was a bugfix for a related thing in 5.6.1 and a couple of > other exit-from-a-trap tweaks involving loop structures that are > pending the next release, but exit from a trap should work (and does > in some simple tests I did). Do you have a simple example, and are > you sure you're not seeing the effects of some of the above options? See the #!/bin/zsh -f script I posted originally - I think it is fairly simple, and zsh -f should ensure the options are in a known default state. When TRAPTERM uses 'exit' rather than 'return', the script does not exit after receiving SIGTERM. With 'return', the script does exit, but the in | remains running. Since it was not backgrounded, I'm not sure how to make sense of the expected behavior based on the options you described above. It seems to me like it should be killed, as there was no way to capture its PID in order to arrange for it to be killed at exit. thank you, Greg >> I didn't expect that, even with the special return handling. So, >> there is no way to exit 0 from a trap, since that is interpreted as >> the signal having been handled, and wanting to continue executing? > Again I'm not seeing this. If I exit zero from an INT trap, the exit > status of the interrupted script is zero. However, if I exit from an > exit trap, the status of the exit trap is ignored and I get the status > from before it was called, e.g., killing a script with SIGINT always > returns 130 even when TRAPEXIT calls exit with a different value. I'm > not sure that's clearly documented anywhere. >> With no traps of either type, should the child sleep remain after the >> script is killed by a signal? > See above RE signal options. Probably yes.