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,HTML_OBFUSCATE_05_10, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 10668 invoked from network); 22 Nov 2022 02:53:27 -0000 Received: from zero.zsh.org (2a02:898:31:0:48:4558:7a:7368) by inbox.vuxu.org with ESMTPUTF8; 22 Nov 2022 02:53:27 -0000 ARC-Seal: i=1; cv=none; a=rsa-sha256; d=zsh.org; s=rsa-20210803; t=1669085607; b=p5WBOlSJncjJpqbKqG+Ohg/supJa7Et4u+lzipMN/ZUvfE3DZBkk0YEz2izZySC4xnMhY60Kvp oIC9O2gyWZkSWTW8Gx9fGsS54f3YmYkYYfGac/Tmg70FZUg07K7O99AJzjWDNb7V6YCr/SA4IN xXGgtu1vE2E/zEDVSeGrNbquhvJIb+WUinNRdZPTYP7KGMaAtkKIXZnjrayjZ4gsqc7ffvLEL0 QWqo10YipYMOsATmJUPG9zK+sn7volWlGHQJwkD4PjWUw5YVxvdw3+9kHK2nIVzqcaYEl1p9wX oA6jJMgPRHdh1w7bC/spFB2R50e8UjCmGmXmw1gyKdyOvA==; ARC-Authentication-Results: i=1; zsh.org; iprev=pass (mail-vk1-f169.google.com) smtp.remote-ip=209.85.221.169; 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=1669085607; bh=EyT4AZcKUkI1HCtbf/o+55maeqQEwh8NkinYn2rDJaM=; 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=QzRQalH9kpV2u+X1yg4bLxI3XFbIyKOzy60bbtqo9/MVE6b6oVuYzfPDmOJvSXaWqz32sec7SM +jGfi+dzQQnhnQnqb346eCfYUxZ35kneKG5Xuo3pDiTU1DOvYBxMvxtgwG+m6mfHb5Sg+LIInd H3dTW7B3E2aXApetMiZ32xs8nYbKLIpKLoNC4xAUAvnylWRuCwbeov3YAjvCl29d4pxU/mzZd6 7hcfhQ8sRzXWW2uuqImb0dCycNzWrp9EMveJ8eNlBEeuSYu+3509HgkH4mvCvd9HrF/Pz/yXNB kRW6aWN5sVI+4t/2N1OHnLY490ktiDxopjKKkygmi7m/Hw==; 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=JAX6QtHIwNXtF266vj0JI42/zHUxKA2KfF0Du4vO9JE=; b=BvuhgBgNYj6aSvBJHR3LCT+Fos EjOz0KwBYTo4AHPXaOM6G42qht0kBp9UtBHwT+JIkWZOnTmRDNyVS0CJL9gTl6oYvuVT6pHqQN6A0 jtii+KNSutQLkV6jY3pUWdRqymAh7LhoOG5WwpPYC+SZMWG5jNBeW7e7+pOco+86q9GlX7VDnN21j NyLgRfSkfpn9d4XP43Lf80GpivfStCdFK/XijUrk+ovdV7x48ioqkoitMeKOwZrzbzmMwCbIo3CYt /jVfbbE1h3QXRCbVCVcMJ7IXl1yZUeI/Dl1vsBA4FOgv9llLWuVhSoVA5dNnrECqNqoo/57milE5W g1CpMPZA==; Received: by zero.zsh.org with local id 1oxJPa-000F3C-1q; Tue, 22 Nov 2022 02:53:26 +0000 Authentication-Results: zsh.org; iprev=pass (mail-vk1-f169.google.com) smtp.remote-ip=209.85.221.169; dkim=pass header.d=gmail.com header.s=20210112 header.a=rsa-sha256; dmarc=pass header.from=gmail.com; arc=none Received: from mail-vk1-f169.google.com ([209.85.221.169]:34738) by zero.zsh.org with esmtps (TLS1.3:TLS_AES_128_GCM_SHA256:128) id 1oxJP8-000Ea8-W9; Tue, 22 Nov 2022 02:53:00 +0000 Received: by mail-vk1-f169.google.com with SMTP id b81so6605822vkf.1; Mon, 21 Nov 2022 18:52:58 -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=JAX6QtHIwNXtF266vj0JI42/zHUxKA2KfF0Du4vO9JE=; b=J+DIuJxA/Dm97aJbJjGNFb7MjxtKTm6ChsFJgG0e4SzmfrCra2fzLeowOj96423oPd +Dwqykmui9X4qYWISwDme84lQI5nGmy6cmaKmiXa19E3EMNrDTHeB7ectPmQ4VK8Tpvy fBua6+/AGU25L7O3a4EVxoFQZNQRIDa4K3Ulooss/bjaxO3GJsdjGFNSL/F2sHJtGVkx 4lKzHmCPc6gTepTxVjQUnA0SAGaR9+j5cEm7bqbyQXJG80QImVYVrCtXchqTwV/ZzpFk 1pxbeDlWjBTihbpFsSyGCP3IdaZTTnMKqMyvXI+t36ycSr/y+MpckEns0TYVS2fadr5A 2cOA== 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=JAX6QtHIwNXtF266vj0JI42/zHUxKA2KfF0Du4vO9JE=; b=nqFE2Xj38WWAcUetBJRoDlRFhiayF3bfwAc8m4NBeaHDZ8/2uMZSQs69of4alD6V0r ufN4bLqbtOQErqdhkpcvfxzEIbS4ZLtFKd6L6ZzLBicxxc1Ud4U+ybAUfxoyHj3R5//A 5UKmGGzcWOffJ8IPx/uqlHEVRcDiamWhW9giaMXGX53xyB4PX73IZvK8s/chMnm6bdNU AOHpuZdkg2/KlX8P17SC3f3CUa4A2uwOD4HkhFdJ13BHXxpAUxMsj1E0UqKCBbnGUsSI w6G6oByYW944jjSQasWz5rGPp2hnfQKhEgXcdKdivSSLF7HNpCT4mLxcu5SlpbrWRczB DCyA== X-Gm-Message-State: ANoB5pn3a9Z4CvUY8JuPwWKQpDhG6f7vKFHb45vhOBBzNfeZvAX2xJbp eb//yPJBJP4RU76yQkvmy9JGSnQ5TIA9S4X8C0Sf8fV7SyA= X-Google-Smtp-Source: AA0mqf5Kss2oULRavBvWzxz6Oi6eDXAGxVrQWWnismYRyc9fnhxCgT8TWF/5QcQt9VnDqi3VorWC6SG7GIk76Y6Jdmo= X-Received: by 2002:a05:6122:ca9:b0:3ac:fba7:fc83 with SMTP id ba41-20020a0561220ca900b003acfba7fc83mr1700780vkb.23.1669085576660; Mon, 21 Nov 2022 18:52:56 -0800 (PST) MIME-Version: 1.0 References: <230a78bb-fa97-4f3a-94a2-86982316274b@app.fastmail.com> In-Reply-To: <230a78bb-fa97-4f3a-94a2-86982316274b@app.fastmail.com> From: Philippe Altherr Date: Tue, 22 Nov 2022 03:52:45 +0100 Message-ID: Subject: Re: [PATCH] Fix ERR_EXIT behavior in function calls and "always" statements To: =?UTF-8?Q?Lawrence_Vel=C3=A1zquez?= Cc: Bart Schaefer , zsh-workers@zsh.org Content-Type: multipart/alternative; boundary="000000000000e58b5605ee0644e3" X-Seq: 51020 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: --000000000000e58b5605ee0644e3 Content-Type: text/plain; charset="UTF-8" > > Each time though, you've removed the NEWS item. Although we've > established that the behavior it describes was not actually > appropriate, there still has been a change in ERR_EXIT behavior that > probably warrants a mention. What's the best description of that? Good point. There is indeed a behavior change but it's more complicated than what you described. I will try to come up with something. Actually my 3 fix patches address 3 different issues. In my opinion, at least 2 of them qualify as bugs but it still makes sense to describe what changes. This suggests that anonymous > functions should *not* behave like normal function calls here. That's debatable. If, like me, you see anonymous functions as some kind of syntactic sugar, then it makes sense that they behave like function calls and exit. However, I can also understand that others rather see them as another type of compound command. In that case, they should not exit. To help decide what to do, here is a table that lists all the different cases and how they behave in the current Zsh, in a patched Zsh, and in a patched Zsh where anonymous functions behave as compound commands: Code Current Zsh Patched Zsh Compound command (and patches) A) false Exit Exit Exit B) false && true No exit No exit No exit C) { false && true } No exit No exit No exit D) () { false } Exit Exit Exit E) () { false && true } Exit Exit *No exit* F) () { { false && true } } No Exit *Exit* No exit G) f() { false }; f Exit Exit Exit H) f() { false && true }; f Exit Exit Exit I) f() { { false && true } }; f No Exit *Exit* *Exit* Currently anonymous functions behave like function calls. My patches don't change that but they change/fix cases F and I to behave as mandated by POSIX. If anonymous functions are changed to behave like compound commands then anonymous functions behave as if the code was inlined. This changes the behavior of case E, which currently exits. Is the compound command behavior a reasonable one? Certainly yes. Is it desirable? I guess that's more debatable. Personally, I am leaning towards the current behavior. I could be convinced otherwise and for sure I could live with the alternative. If you care about code complexity (of the Zsh implementation), then that would be an argument against the compound command option as it requires additional code. However, in my opinion, languages should in general NOT be designed to simplify their implementation but rather to simplify their usage. Does it? These seem to behave identically with Philippe's latest > patches; am I overlooking something? No, with my patch "false && true" and "{ false && true}" now always behave the same. Frankly I'm > still not certain that the extra level of { } should matter in the > function example. With my patches, they no longer do. Note however that the behaviors of the following examples, which are unaffected by my patches: set -e > { false && true } # does not exit > () { false && true } # exits As you can see, with my patches, an extra level of { } no longer changes any behavior. However, already today, anonymous functions don't always behave the same as the inlined code. FYI: Here are my next steps - Write NEWS for my 3 fixes. - Better document the role and usage of noerrexit and this_noerrexit. - Try to fix "eval", "source", and possibly a bunch of other related cases. Unless anyone sees a reason not to, it would be nice to submit my first pacth, which reverts Bart's changes. For the other patches, I have at the very least to first add a NEWS item. Philippe --000000000000e58b5605ee0644e3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Each tim= e though, you've removed the NEWS item.=C2=A0 Although we've
est= ablished that the behavior it describes was not actually
appropriate, th= ere still has been a change in ERR_EXIT behavior that
probably warrants = a mention.=C2=A0 What's the best description of that?
=
Good point. There is indeed a behavior change but it's m= ore complicated than what you described. I will try to come up with somethi= ng. Actually my 3 fix patches address=C2=A03 different issues. In my opinio= n, at least 2 of them qualify as bugs but it still makes sense to describe = what changes.

This suggests that anonymous
functions should *not* behave li= ke normal function calls here.

That's d= ebatable. If, like me, you see anonymous functions as some kind of syntacti= c sugar, then it makes sense that they behave like function calls and exit.= However, I can also understand that others rather see them as another type= of compound command. In that case, they should not exit.

To help decide what to do, here is a table that lists all the diffe= rent cases and how they behave in the current Zsh, in a patched Zsh, and in= a patched Zsh where anonymous functions behave as compound commands:
=

=C2=A0 =C2=A0Code= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Current Zsh=C2=A0 =C2=A0 =C2=A0Patched Zsh= =C2=A0 =C2=A0 =C2=A0Compound command (and patches)
A)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0false=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Exit=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 Exit=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Exit=
B)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0false && true=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 No exit=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0No exi= t=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0No exit
C)=C2=A0 =C2=A0 =C2=A0{=C2= =A0 =C2=A0false && true=C2=A0 =C2=A0}=C2=A0 =C2=A0 =C2=A0 =C2=A0 No= exit=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0No exit=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0No exit
D)=C2=A0 () {=C2=A0 =C2=A0false=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0}=C2=A0 =C2=A0 =C2=A0 =C2=A0 Exit=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Exit=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Exit
= E)=C2=A0 () {=C2=A0 =C2=A0false && true=C2=A0 =C2=A0}=C2=A0 =C2=A0 = =C2=A0 =C2=A0 Exit=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Exit=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= No exit=C2=A0 =C2=A0=C2=A0
F)=C2= =A0 () { { false && true } }=C2=A0 =C2=A0 =C2=A0 =C2=A0 No Exit=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Exit=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 No exit
G) f() {=C2=A0 =C2=A0false=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0}; f=C2=A0 =C2=A0 =C2=A0Exit=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 Exit=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Exit
H) = f() {=C2=A0 =C2=A0false && true=C2=A0 =C2=A0}; f=C2=A0 =C2=A0 =C2= =A0Exit=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Exit=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0Exit<= /span>=C2=A0 =C2=A0=C2=A0
I) f() { { false &= ;& true } }; f=C2=A0 =C2=A0 =C2=A0No Exit=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0Exit=C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 Exit

Curre= ntly anonymous functions behave like function calls. My patches don't c= hange that but they change/fix cases F and I to behave as mandated by POSIX= . If anonymous functions are changed to behave like compound=C2=A0commands = then anonymous functions behave as if the code was inlined. This changes th= e behavior of case E, which currently exits.

Is th= e compound command behavior a reasonable=C2=A0one? Certainly yes. Is it des= irable? I guess that's more debatable. Personally, I am leaning towards= the current behavior. I could be convinced otherwise and for sure I could = live with the alternative.

If you care about code = complexity (of the Zsh implementation), then that would be an argument agai= nst the compound=C2=A0command option as it requires additional code. Howeve= r, in my opinion, languages should in general NOT be designed to simplify t= heir implementation but rather to simplify=C2=A0their usage.

=
Does it?=C2=A0 Thes= e seem to behave identically with Philippe's latest
patches; am I ov= erlooking something?

No, with my patch &quo= t;false && true" and "{ false && true}" now = always behave the same.

Frankly I'm
still not certain that the extra leve= l of { } should matter in the
function example.

With my patches, they no longer do. Note however that the behaviors= of the following examples, which are unaffected by my patches:
<= br>
set -e
{ fals= e && true } # does not exit
() { false && true } # exits=

As you can see, with my patches, an extra = level of { } no longer changes any behavior. However, already today, anonym= ous functions don't always behave the same as the inlined code.

FYI: Here are my next steps
- Write NEWS = for my 3 fixes.
- Better document the role and usage of noerrexit= and this_noerrexit.
- Try to fix "eval", "source&= quot;, and possibly a bunch of other related cases.

Unless anyone sees a reason not to, it would be nice to submit my first p= acth, which reverts Bart's changes. For the other patches, I have at th= e very least to first add a NEWS item.

Philippe

--000000000000e58b5605ee0644e3--