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 16191 invoked from network); 8 Nov 2022 04:59:05 -0000 Received: from zero.zsh.org (2a02:898:31:0:48:4558:7a:7368) by inbox.vuxu.org with ESMTPUTF8; 8 Nov 2022 04:59:05 -0000 ARC-Seal: i=1; cv=none; a=rsa-sha256; d=zsh.org; s=rsa-20210803; t=1667883545; b=ZaZuTESfsZam/6tJijXkenQEie3zJrUyN3MP79vB117SfaBWax1NkHvOCZYzcPxxQ7OHDz6GYm Uox4+79zRq11v2yt/GBs5k4SbnzF6eaZGMsCkSBNlMPabqkZzSS/JV5/sl5bpgxGmrwxEQ5N7X BXrk9sg9Y7LeCtrlsAEnvLNKALyJxnJtbTVuQdoD7EVOkRFdpEu2wN0cYVUzltHB6q3jenNAv+ 170EIFyeqCjsXXUERf9plxqG6eIrRGca0dLTtKqkruTYSKM1BbNdipjPygRo8oQJG30kYNMlwi C32z+xEADyskwxXLSiBPmjF4B5eYZqXEJwUZkb+ei9yU0A==; ARC-Authentication-Results: i=1; zsh.org; iprev=pass (mail-vs1-f41.google.com) smtp.remote-ip=209.85.217.41; 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=1667883545; bh=pHHatCNSvm8b1OMQhvrs70u+MVpMoFQu5vEKitdTOmE=; 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=rDtB3LEQoWHYaD48ubNf+10K+nm/StEjIXy8yz6dL8dL2+X/m1+PyR30wTs7/mdESzHzTZpdGv 5H3fNjz5rxZ32AisvikQ5FEfQOP2bBxIh1hZUyjTwH81BjsyuOqdJwO5HxsXghEU/tCsx9yst4 ElNkDz/mRpo755gtzF68wlyA9alW0P/IjjIcMVWcE+4IQq5MbbDE5PufkS5vbr8ZRXzvDNlCok ihHB32McGH5rdlqt3sWpaO4Dz6IbBXPZ2bHaCQHUnoe/py7QTQCi08tJH/wItBOcFWy0O8shjF PkJGCwKCkDqxn/42xYKGtXInfMffvGmlM3M/gS4xMFM77g==; 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=YzU0gNgt4CZ2UgRF76+2wPoPpnVIX3uz0iSWyxnDFI4=; b=Tw7NNK45kbLgXt5w86ONANjyqm btxTSguJwBlc0py12UqI9RZAnUn3GhwaIcYRS90PWHckPtYhU1R3zT5H3zlOltgYOLFzrZf4Mmkpy iQSX+XWlLYpBtic4N3Ikmhdvbi7f4ytR8REOY9BpSzrwKQ9Zf2x9GbS3Re7v1wjlK1TFTl/8EzopZ TIhgUGYhgcj7ivXK4zJNmn4KqrYFa+zbXobSuyDr5nm11s586JB6QR4aHJEE0xa+IzY2bqaUX1wPJ 0mOejgPjhddd2/BR8CBmGMw/e11P/hBvVjWmMoE6ygEKR0qa+Bu6/z4poGbDAtUv4FZz44TomV88k BoCjkGpA==; Received: by zero.zsh.org with local id 1osGhS-0000lk-QP; Tue, 08 Nov 2022 04:59:02 +0000 Authentication-Results: zsh.org; iprev=pass (mail-vs1-f41.google.com) smtp.remote-ip=209.85.217.41; 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-f41.google.com ([209.85.217.41]:37885) by zero.zsh.org with esmtps (TLS1.3:TLS_AES_128_GCM_SHA256:128) id 1osGgq-0000Px-BG; Tue, 08 Nov 2022 04:58:25 +0000 Received: by mail-vs1-f41.google.com with SMTP id z189so12633424vsb.4 for ; Mon, 07 Nov 2022 20:58:24 -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=YzU0gNgt4CZ2UgRF76+2wPoPpnVIX3uz0iSWyxnDFI4=; b=Xk3EVOU7ZphT6aEXYRtOnnI/ccW6DNVRrONDlsC/1DsZy4Zj1obbgDca8cxeqUC8Tc QGrzUpirgYnYga9rGhin8gv32coz+wn2cu1Do6bUbk/ZvH8yQxk6y1AOy0aqRZfiVSpZ r06eXVNEdGwWfCAtEFhdNWtAxGZzf2hF/bpk98vM8j0yrxJOezJz1IzxeN3IzcTKBS5l 1RyLfJpSDW19F/PCoMoknzGliQE2DvIDbJe+UpWiz45Cyp3lVYSDTLd2LKA7exokLtsk /yRhAvusYtWUke3/AF/iQC+2/ym69OExswY72oBCM4ZqnvLJOB3hh4kMo5h/5RvJITN+ VAfQ== 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=YzU0gNgt4CZ2UgRF76+2wPoPpnVIX3uz0iSWyxnDFI4=; b=8GUUG2J5g/dd2UKbHrekzUKmQyhluKMu/I+opONZRCc3Iy7PjzjVbqvHUIpejS6bhU YKzhI4zOktOvTl/vZGrWU83Mp5trOq/cFAk6KNEh0KXvdF05NxAOotzeWMl091aA51P0 gpQUoLePRhCy+0zxrMZB/+T6qkQ8tWGhqZRalJlqFPsYJ1F/8i9vP2yy+0dYNsupvqAb AB5lUJt2uGLTqniJEiCeEWAnrLhvQIEPO48Hlm85kLVCnFjdLzoxVe/hLihN3XDPhS+j JIKZrlOAX7w3ZlwM1Mw3aMrHk3nK/EmPaymcMMvOuK9Y4hpKAIeDfh2amdSWH/vel0Bf 6yJw== X-Gm-Message-State: ACrzQf33ficbarhXfenO425AXVE/FwnqXF6qhMAMZWCzFj52LhqSExOE 031BceJp50cTln6gl/NnZCE9hsbTASJhPehmspIy5izAMXE= X-Google-Smtp-Source: AMsMyM4xDTq5C23fGgMhHK8fItM02cJjB9fIrMPgfwL1qMM3sE0nBdlQW1WPJYQCKnj/C4ldF7uT0HShGXPL97X2RZg= X-Received: by 2002:a67:7104:0:b0:3aa:31b2:ff0b with SMTP id m4-20020a677104000000b003aa31b2ff0bmr26057519vsc.56.1667883502728; Mon, 07 Nov 2022 20:58:22 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Philippe Altherr Date: Tue, 8 Nov 2022 05:58:11 +0100 Message-ID: Subject: Re: Inconsistent behavior of ERR_EXIT with conditionals To: Bart Schaefer Cc: zsh-workers@zsh.org Content-Type: multipart/alternative; boundary="000000000000b4f9bf05ecee634b" X-Seq: 50910 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: --000000000000b4f9bf05ecee634b Content-Type: text/plain; charset="UTF-8" Hi Bart, Thanks for your replies. Great to see that this may get fixed. I feared that it could be a case where it's too risky to change the existing behavior, even if it's incorrect. However, before fixing anything, I think that we should get a clear understanding of what is the expected behavior of ERR_EXIT. Indeed, there are more cases where I think that Zsh fails to do the right thing. My understanding of ERR_EXIT is that it should trigger an exit of the shell immediately after any command returns with a non-zero exit status, with the exception of commands whose exit status stands for a condition (for example in the condition of an if statement or on the left of an || operator). In other words, when ERR_EXIT is enabled, any command that unexpectedly fails should trigger an immediate exit of the shell. Below is a short script that exhibits most of the cases that I know where Zsh fails to behave as described above. The function EXIT is used everywhere where I expect Zsh to trigger an exit (sometimes from a sub-shell). In other words, none of the EXIT function calls should be executed. Unfortunately, all the calls with an argument "Failure-?" are executed. #!/bin/zsh -e > > function EXIT() { echo $1 1>&2 } > > : $(false; EXIT Success-A); EXIT Failure-a > local v=$(false; EXIT Success-B); EXIT Failure-b > if false; EXIT Failure-c; true; then true; fi > { false; EXIT Failure-d; true } && true > false && true; EXIT Failure-e > ! true; EXIT Failure-f > The output is the following: Failure-a > Failure-b > Failure-c > Failure-d > Failure-e > Failure-f > Regarding your proposed fix, I'll have to take a closer look. A few days ago, I looked at exec.c , noticed the noerrexit variables, and figured that was probably the key to some of the bugs but I would need much more time to understand what exactly is going on. I'll at least try to build Zsh on my machine so that I can try your fix. Philippe On Mon, Nov 7, 2022 at 4:50 AM Bart Schaefer wrote: > On Sun, Nov 6, 2022 at 12:45 PM Bart Schaefer > wrote: > > > > [...] I suspect this fix may be needed elsewhere ... there are a > > bunch of similar cases for multi-line shell constructs in Src/loop.c > > Those are: > for > select > while > repeat > if > case > > Does anyone disagree that Philippe's examples demonstrate that "if" > and "case" should get this treatment? > > More questionable are the looping constructs. I can't come up with a > way to have the loop end in an error state without the whole shell > ERREXITing before reaching the end of the loop body. The value of > this_noerrexit matters at all, as far as I can tell, only to suppress > the false-condition that ends a "while" loop, and is meaningless in > for/select/repeat? > --000000000000b4f9bf05ecee634b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi=C2=A0Bart,

Thanks for your replies. = Great to see that this may get fixed. I feared that it could be a case wher= e it's too risky to change=C2=A0the existing behavior, even if it's= incorrect. However, before fixing anything, I think that we should get a c= lear understanding of what is the expected behavior of ERR_EXIT. Indeed, th= ere are more cases where I think that Zsh fails to do the right thing.

My understanding of ERR_EXIT is that it should trigger= an exit of the shell immediately=C2=A0after any command returns with a non= -zero exit status, with the exception of commands whose exit status stands = for a condition (for example in the condition of an if statement or on the = left of an || operator). In other words, when=C2=A0ERR_EXIT is enabled, any= command that unexpectedly fails should trigger an immediate exit of the sh= ell.

Below is a short script that exhibits mos= t of the cases that I know where Zsh fails to behave=C2=A0as described abov= e. The function EXIT is used everywhere where I expect Zsh to trigger an ex= it (sometimes from a sub-shell). In other words, none of the EXIT function = calls should be executed. Unfortunately, all the calls with an argument &qu= ot;Failure-?" are executed.

#!/bin/zsh -e

function EXIT() { echo $1 = 1>&2 }

: $(false; EXIT Success-A); EXIT Failure-a
local v= =3D$(false; EXIT Success-B); EXIT Failure-b
if false; EXIT Failure-c; tr= ue; then true; fi
{ false; EXIT Failure-d; true } && true
fal= se && true; EXIT Failure-e
! true; EXIT Failure-f

The output is the following:

Failure-a
Failure-b
Fai= lure-c
Failure-d
Failure-e
Failure-f
=C2=A0
Regarding your proposed fix, I'll have to take a closer l= ook. A few days ago, I looked at=C2=A0exec.c,=C2=A0noticed the=C2=A0noerr= exit variables, and figured that was probably the key to some of the bugs b= ut I would need much more time to understand what exactly is going on. I= 9;ll at least try to build Zsh on my machine so that I can try your fix.

Philippe

<= /div>

On Mon, Nov 7, 2022 at 4:50 AM Bart Schaefer <schaefer@brasslantern.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">On Sun, Nov 6, 2022 at 12:= 45 PM Bart Schaefer <schaefer@brasslantern.com> wrote:
>
> [...] I suspect this fix may be needed elsewhere ... there are a
> bunch of similar cases for multi-line shell constructs in Src/loop.c
Those are:
=C2=A0 for
=C2=A0 select
=C2=A0 while
=C2=A0 repeat
=C2=A0 if
=C2=A0 case

Does anyone disagree that Philippe's examples demonstrate that "if= "
and "case" should get this treatment?

More questionable are the looping constructs.=C2=A0 I can't come up wit= h a
way to have the loop end in an error state without the whole shell
ERREXITing before reaching the end of the loop body.=C2=A0 The value of
this_noerrexit matters at all, as far as I can tell, only to suppress
the false-condition that ends a "while" loop, and is meaningless = in
for/select/repeat?
--000000000000b4f9bf05ecee634b--