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.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 4966 invoked from network); 9 Nov 2022 04:12:11 -0000 Received: from zero.zsh.org (2a02:898:31:0:48:4558:7a:7368) by inbox.vuxu.org with ESMTPUTF8; 9 Nov 2022 04:12:11 -0000 ARC-Seal: i=1; cv=none; a=rsa-sha256; d=zsh.org; s=rsa-20210803; t=1667967131; b=PIxoz2FhGdzJgXz5ZUv3uZT3IxscN4uiI5TfIsQwgPw0glgj/PdXm8C/nLjq2Tq2/+f57oo35W CLLy9jRRvKfGtdRHDhE6CmgrswjeKN1GR7TAoGLt06PZN/yuhXfZy8sIp4Q/LIgCAXFCXrQs5j QY3j2VlI6JdSga2p8oOCfYlifG7heoqImok5BdvnE936txR+2HMsACXdYqEdGuTCE6NhwKkhXR 2P67VTqeKj1iIPD3mWWMAd7DieHmUlSiGN44NukPgTcYdn+cbSC0ZdRBDjUKMHkSQkKi+XPpWU Ubc7inwmMhZEvaSfz/KOSYG5+Q5QL7acgtT6ILSrTR/7OQ==; ARC-Authentication-Results: i=1; zsh.org; iprev=pass (mail-vs1-f48.google.com) smtp.remote-ip=209.85.217.48; dkim=pass header.d=gmail.com header.s=20210112 header.a=rsa-sha256; dmarc=pass header.from=gmail.com; arc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed; d=zsh.org; s=rsa-20210803; t=1667967131; bh=qTSMZpd5eH8cXGSVB/xoNVZpV8/CkqhAyS4vCK3jx2o=; h=List-Archive:List-Owner:List-Post:List-Unsubscribe:List-Subscribe:List-Help: List-Id:Sender:Content-Type:Cc:To:Subject:Message-ID:Date:From:In-Reply-To: References:MIME-Version:DKIM-Signature:DKIM-Signature; b=fozRMk1XTJb2k15v4Vers4UeN0x7h9FKklUlY/9FlAfNZ8Rzmyi9o9XjTUPBGzHVz2wpWRWmW3 3f8jb/992LJw/wofsSQ5qohMsGJ2x4UNZKOX1o9eHwW9QTKD9qtp/ofjQViVYXSu8u5NVapKmJ n4JwKHsbqgLwmz1D2s27BsGnO/PSKswM5y3M7s67JIledwaRyfeEWq79UnKJ2saEdve/zA9lpd 4j4iDmPM27qrDOi3FWcbwE2W6KRk24ZbRIQkVpwzaEPZmR3UOTCUAzGRF4/eJoJCU/k2L2bHHn OyxhPJ3DtK0v6MhCnKumRtN8yviCP9ajaqZp/45w+2YwQg==; 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:Cc:To:Subject:Message-ID :Date:From:In-Reply-To:References:MIME-Version:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID; bh=qc2BfRU/OMJ19PFVeKusXV+wK3+3ynFzNWoupoIjnTs=; b=sEXR6BPL82ZvBs/9en4anjgDRm RnLRGxvuV3UAF2D/eXMukXk07Q4tE7q+1rRmwmQ03c5byegRXLJ8qqCGY/wof/qfl+DxaxBBgD2Ip eTaMV4TzPi0R84trqSdcDoC52HHwJPulBzSeWq4Um77F6urtVLoaD4bMyekmLC556W1+wnNd3I1YE bGAahFRloS8H7r7jKlRvCPVmIOCK5O3Xn6F334raRmxxUcKBrGMMdJJaXyu+8n4z0xhA1j34rSq9x EXHy/htKZ6wMIFcCk/yeQfUrB217SlHy2/cDSkOCvTsAtA0EILpbgbMqr/hkcv6xDyzHHhwPeWov1 uslQ/4Xg==; Received: by zero.zsh.org with local id 1oscRe-0005yU-Ta; Wed, 09 Nov 2022 04:12:11 +0000 Authentication-Results: zsh.org; iprev=pass (mail-vs1-f48.google.com) smtp.remote-ip=209.85.217.48; dkim=pass header.d=gmail.com header.s=20210112 header.a=rsa-sha256; dmarc=pass header.from=gmail.com; arc=none Received: from mail-vs1-f48.google.com ([209.85.217.48]:41888) by zero.zsh.org with esmtps (TLS1.3:TLS_AES_128_GCM_SHA256:128) id 1oscRL-0005eP-4o; Wed, 09 Nov 2022 04:11:51 +0000 Received: by mail-vs1-f48.google.com with SMTP id t5so15547263vsh.8; Tue, 08 Nov 2022 20:11:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=qc2BfRU/OMJ19PFVeKusXV+wK3+3ynFzNWoupoIjnTs=; b=XOOfafiuqzrbZ2Ja+bBwTh6Pc5InanceVfa9JlYrUnAybBm58QTfuPrY89FQfd2ka/ 3pnWuOU4K6OhlkIfCcrsaEpkxfAeYd6AdVbA4YhAy2E60tYXa0QSh4lBLykP+uacaSkL K9i0FmuN/zjqt5BieeKb4MMgJOXjkMwmxKS6/bXzDeDFPZOIfc3Eygt5tsWy7Rz6X28h QB1tMzXxohk5U5fq29QyW8nKBNW5+naQFgpwmh08dB3dsVvtvqq+k0zQlPHZmII6793H XP17x1mFW14EJyXoOrF4dVxK2cCudcsC4mqbDPQEkTcpRM6maBKxPehSlo0Jk+NR67aF B9zQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=qc2BfRU/OMJ19PFVeKusXV+wK3+3ynFzNWoupoIjnTs=; b=FiWgHSz6GAdS8avD7KVx0athQRbJ8GYRcQJp+TCjSgXoyHKtuJAJXMYhgcasfHExh9 LfPAIO+Tekaj+Wpm/Nb1tS+l/Ax02LWKxWi4y3IB+Dm4FN4Kqie6bf25cHRX9r1chA/p p4ygPRXFiLU/mztMrvIKP/yD+knj7bKfUmkxvt0V6WU2fC/yEymcj/sa7WnC5dyPaFLz W5X0tmrdkTla5AQoaVkPql5biL0XuMsntHmhXz+XHeHkTgRKE8aV+CmJz5e8WGkEzPPv PcWsZ8x/eNv7juqIR27t4W6advKl4BUHDCLUxiOF8U2Hjuk9rySZ1pz+Ue9GLr4MbLon /eTA== X-Gm-Message-State: ACrzQf2rOeSE8kyZFvpOrQakkMRqH+r8PZhwj5jxmWPXdyifswto1o/R 8NMZ0HBNfOCr1IzX5DBKktOk95vvbVtGF6L+3qQzdgJMFLI= X-Google-Smtp-Source: AMsMyM58RoRGEU+EVEaHbriMEHuhQdhzLhyx0/XuusMp5uVOZSbtMi1Xb7NwJSHGNSz7bT0E2vFIsvnlfU4RrYzOxbU= X-Received: by 2002:a67:7104:0:b0:3aa:31b2:ff0b with SMTP id m4-20020a677104000000b003aa31b2ff0bmr29211445vsc.56.1667967108415; Tue, 08 Nov 2022 20:11:48 -0800 (PST) MIME-Version: 1.0 References: <1edb7786-f0b2-4830-88fa-99a19bda39e2@app.fastmail.com> In-Reply-To: From: Philippe Altherr Date: Wed, 9 Nov 2022 05:11:37 +0100 Message-ID: Subject: Re: Inconsistent behavior of ERR_EXIT with conditionals To: Bart Schaefer Cc: =?UTF-8?Q?Lawrence_Vel=C3=A1zquez?= , zsh-workers@zsh.org Content-Type: multipart/alternative; boundary="000000000000fe85fd05ed01da88" X-Seq: 50921 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: --000000000000fe85fd05ed01da88 Content-Type: text/plain; charset="UTF-8" > > All of 1,3,4 are fixed by my patch in workers/50897 That's great! It's a small win but I actually (re-)stumbled on the problem of conditional expressions because of one of these cases. So it's good to see that they can be fixed. My ultimate goal is to be able to run Zsh scripts with the guarantee that if any command unexpectedly fails (i.e., if any command whose result is not otherwise checked returns a non-zero exit status), then the whole *script* (not just some subshells) stops immediately. Wouldn't you agree that this would be a useful feature? The question is how can this be achieved. On the surface, it looks like enabling ERR_EXIT does the trick. However there are several cases where ERR_EXIT fails to do the job. These cases are of two categories: 1. *Non-triggering:* In some contexts, commands whose result is not otherwise checked don't trigger a shell exit when they return a non-zero exit status even when ERR_EXIT is enabled, e.g., the "false" command in "{false; true} && true" doesn't trigger a shell exit. 2. *Non-propagation:* In some contexts, errors in subshells don't propagate to the parent shell, e.g., the "false" in "local var=$(false)" triggers an exit in the subshell of the command substitution but the assignment ignores the result of the command substitution and thus the parent shell fails to exit in turn. I hoped that some of these cases could be "fixed" but I have now checked the POSIX specification and as you both pointed out, for most of them POSIX specifies that they have to work as they currently do (this doesn't include Lawrence's example 1,3,4, which should indeed be fixed). The first developer is wrong. That's not what -e is for. A script > should be correct WITHOUT the use of -e ... the purpose of -e is to > uncover cases where the developer made a mistake, not to be an > integral part of the script function. I can agree with that but consider that the developer's mistake was to use a ";" instead of an "&&" in the "backup" function. My broader point was that the same error (or developer mistake) in a function "foo" triggers an exit if "foo" is called from a plain statement but not if it's called from within a condition. Wouldn't you agree that it's unfortunate that the same error/mistake may or may not trigger an exit depending on whether it's executed outside or inside a condition? Again, wrong. "{ false; true }" is a single statement because of the > braces. When that statement is followed by || the result of the > ENTIRE statement is considered to have been "checked". > Similarly, in "if false; true; then" the conditional part is > considered as a single statement whose result is "checked". Indeed, POSIX states "The -e setting shall be ignored when executing the compound list following the while, until, if, or elif reserved word, a pipeline beginning with the ! reserved word, or any command of an AND-OR list other than the last.", so there is unfortunately no way this can be changed, at least in the context of ERR_EXIT. Is all hope lost? Not necessarily. The non-propagation issues can be worked around. That's what my zabort does by configuring a ZERR trap that forcibly kills all parent shells from within the subshell where the error occurred. Unfortunately, I don't see how the non-triggering issues could be worked around. For these some change is needed in Zsh but I agree that changing the behavior of ERR_EXIT isn't the way to go as it should remain POSIX compliant. What could work is to implement a new shell option ERR_EXIT_STRICT, which triggers an exit on any command that returns a non-zero exit status and whose result isn't checked otherwise. Only one of ERR_EXIT and ERR_EXIT_STRICT could be enabled at any given time. *Would you agree to add a new shell option if it allows to run Zsh scripts such that if any command unexpectedly fails the script immediately stops (and its implementation doesn't require too complex changes)?* If yes, I may look into implementing it. Philippe --000000000000fe85fd05ed01da88 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
All of 1,3,4 are fixed by my patch in workers/50897
=

That's great! It's a small win but I actually (= re-)stumbled on the problem of conditional expressions because of one of th= ese cases. So it's good to see that they can be fixed.


My ultimate goal is to be able to run Zsh scripts w= ith the guarantee that if any command unexpectedly fails (i.e., if any comm= and whose result is not otherwise checked returns a non-zero exit status), = then the whole=C2=A0script=C2=A0(not just some subshells) stops imme= diately. Wouldn't you agree that this would be a useful feature?

The question is how can this be achieved. On the sur= face, it looks like enabling ERR_EXIT does the trick. However there are sev= eral cases where ERR_EXIT fails to do the job. These cases are of two categ= ories:
  1. Non-triggering: In some contexts, commands = whose result is not otherwise checked don't trigger a shell exit when t= hey return a non-zero exit status even when ERR_EXIT is enabled, e.g., the = "false" command in "{false; true} && true" does= n't trigger a shell exit.
  2. Non-propagation: In some conte= xts, errors in subshells don't propagate to the parent shell, e.g., the= "false" in "local var=3D$(false)" triggers an exit in = the subshell of the command substitution but the assignment ignores the res= ult of the command substitution and thus the parent shell fails to exit in = turn.
I hoped that some of these cases could be "fixed&q= uot; but I have now checked the POSIX specification and as you both pointed= out, for most of them POSIX specifies that they have to work as they curre= ntly do (this doesn't=C2=A0include Lawrence's example=C2=A01,3,4, w= hich should indeed be fixed).

The first developer is wrong.=C2=A0 That&#= 39;s not what -e is for.=C2=A0 A script
should be correct WITHOUT the us= e of -e ... the purpose of -e is to
uncover cases where the developer ma= de a mistake, not to be an
integral part of the script function.

I can agree with that but consider that the=C2=A0d= eveloper's mistake was to use a ";" instead of an "&= &" in the "backup" function. My broader point was that t= he same error (or developer mistake) in a function "foo" triggers= an exit if "foo" is called from a plain statement but not if it&= #39;s called from within a condition. Wouldn't you agree that it's = unfortunate that the same error/mistake may or may not trigger an exit depe= nding on whether it's executed outside or inside a condition?

Again, wrong. = =C2=A0"{ false; true }" is a single statement because of the
b= races.=C2=A0 When that statement is followed by || the result of the
ENT= IRE statement is considered to have been "checked".
Similarly,= in "if false; true; then" the conditional part is
considered = as a single statement whose result is "checked".

Indeed, POSIX states "The -e setting shall be ignored = when executing the compound list following the while, until, if, or elif re= served word, a pipeline beginning with the ! reserved word, or any command = of an AND-OR list other than the last.", so there is unfortunately no = way this can be changed, at least in the context of ERR_EXIT.

Is all hope lost? Not=C2=A0necessarily. The non-= propagation issues can be worked around. That's what my=C2=A0zabort=C2=A0does by configuring a ZERR trap that forcibly=C2= =A0kills all parent shells from within the subshell where the error occurre= d. Unfortunately, I don't see how the non-triggering issues could be wo= rked around. For these some change is needed in Zsh but I agree that changi= ng the behavior of ERR_EXIT isn't the way to go as it should remain POS= IX compliant. What could work is to implement a new shell option=C2=A0ERR_E= XIT_STRICT, which triggers an exit on any command that returns a non-zero e= xit status and whose result isn't checked otherwise. Only one of ERR_EX= IT and ERR_EXIT_STRICT could be enabled at any given time.

Would you agree to add a new shell option if it allows to run Z= sh scripts such that=C2=A0if any command unexpectedly fails the script imme= diately stops (and its implementation doesn't require too complex chang= es)? If yes, I may look into implementing it.

= Philippe

--000000000000fe85fd05ed01da88--