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 24468 invoked from network); 13 Dec 2022 00:33:58 -0000 Received: from zero.zsh.org (2a02:898:31:0:48:4558:7a:7368) by inbox.vuxu.org with ESMTPUTF8; 13 Dec 2022 00:33:58 -0000 ARC-Seal: i=1; cv=none; a=rsa-sha256; d=zsh.org; s=rsa-20210803; t=1670891639; b=i5RULk6xQauAqR8N20zHytvdhcLsjDyj22XMUa+BkEqqOfTNLRrBLpRAZ5c6ypVDOY6YyJi6Eq An4bujIEqaE5bD2ckOd07WdQrz7fVRKdFVjW0Wr3dwSAxkxt0rDOaLyFdecmQRRKVnvnKv6qiq aWoMVAlByH07f6bS63o0Ec7Krq22+/NUplGUKo095bUJPHiGgWUXVkyfVpiGjqropH5onl0J+M X6D+C+9s2LkVRejUjoZgEXvpc2ViEfFTGzO+m9Dq5RFRZV62gB2+fg8X4eYWCuSsz/tSmRZOG/ E5ayera7/8zFxfagy59j3cwnqz8VU8+uQsTFEm9nFp/UJw==; ARC-Authentication-Results: i=1; zsh.org; iprev=pass (mail-vs1-f45.google.com) smtp.remote-ip=209.85.217.45; 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=1670891639; bh=Cu3NhIXOeXFECKPUgjuaRep7InmCkr89tig+HsfM2U8=; 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=VlBjW+kCAtuqQ7bhXv/U70NacOl7wK0YQwIUIKzmd3zQF+Ll10NA55NFrRqpUBHYQQvSSV0W03 FpzSdGjSVMnN422U5LyIe8XBjCvD5z2iTtVaw+USNPWTyldvNVnOqHoDqvHMuWp8w36W0QZCpr 6YzaBPvcWrWLMo3Df7gPo5rOKagx61ho6QBzi3z43japLa0+jsMpFwxh3gd9mK/ek9BCdOsMRv waL7Noj6rh472k9/LN3AIiJlCKuxwuDIVLy+GVb3lTqrtlqNlC6un6ENBoo83cbCT9685MeTHO lYtDHiq1x2XXmnYaWug+/ExYOCSNdTWgl6NQgOz3j3tMkA==; 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=P0OwLkdPGgpw1d/OHFNBfMQmg3WIwgQBb36enQATgow=; b=AbsibT47vnv5Y9LevXnifqR1gU j9DP/BR8exkdqLdmXq9mhFXMikSebTiWOooFJ62qglUuI/7ZckhtXWSbVsndqDzci1nWkTz7wRqPS QyO80B2t68AFEEyEuB1KBwWb1Kwpm1WsvQpImUCzsmrJ0b6gCWOoGqhXPXpys3o8glxkV0r94XTmg anvFgjgA8pBG3OW/BOw+uW6xCRcMtvE6r+vmalImkGZ94o6wepp90kKfQBFsRknx07bcQ94NkUE5d MiH8FlO+y/GkGT+UHJWc1i46Xn0pQJkHg7Pd2+Q7HsqluJyZzrvrtH/d3Kndj4DSvdw1uMAuWpnAK xbRtQFyA==; Received: by zero.zsh.org with local id 1p4tF8-000Amc-4y; Tue, 13 Dec 2022 00:33:58 +0000 Authentication-Results: zsh.org; iprev=pass (mail-vs1-f45.google.com) smtp.remote-ip=209.85.217.45; 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-f45.google.com ([209.85.217.45]:40699) by zero.zsh.org with esmtps (TLS1.3:TLS_AES_128_GCM_SHA256:128) id 1p4tEb-000ASX-I7; Tue, 13 Dec 2022 00:33:25 +0000 Received: by mail-vs1-f45.google.com with SMTP id 3so13108979vsq.7; Mon, 12 Dec 2022 16:33:25 -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=P0OwLkdPGgpw1d/OHFNBfMQmg3WIwgQBb36enQATgow=; b=FBeOt1+C0+ewoK0W7YnOcSa24sQPpPRk2vqQp6Kr9hkQUm2LkQucsZLSZIfnyyeJM3 +8+3sCYpd54xKGJuWm1w2YGEIXCYFV14YE9K3yPeti9IaAkECOq8Gi6sQe/tuuV4RkY3 eMSRPx3n5W4sR6SUB0l3EpfUxL5jWs4U+AOaJG3Og6mb4tOsdp++nixe2+zbOX5z5FNU i3WvsFGyaD1aSSevGoJXPSjwXKCxre53u3+x1DEgGnmfHIaUpXOPSbUEtwmQgcybFJen z+5l0uNMF7mYTKE7yGf6fjhSbwuEk+bbZBhG/DMWfXZITZm7ipIvi2CRqj2hWdKRvlA1 sr6g== 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=P0OwLkdPGgpw1d/OHFNBfMQmg3WIwgQBb36enQATgow=; b=8POITMpYuPrTE8eKUSLrKuXB20BPBSOnhbjgC/sxdQ2CZA7I1BNR2kne11qkv3FLlX M0e2l4olji8kjHKZcbg41z0W6FUl+GInWxAv6e8c6tjEWzVKlzKNj+dS8BGCpJpccY/h SLC1YPGiDCSsqMrKLybjk4E/bN5QsRazmqftiAax5J5qrqyOYQpBhPzxoFmgVQs+qsdv 1Jq3bCyZGhbqDZxdOlWGce/sgqHWZUBwPWEZup6X8Nc3+PzAzYVZKMvVoMynEwL62iWW HvSF4NgdaB+iHSiG03oTWgcjGJehGf9F7Zd9xa/JQwiMRXsx9J6skeSRAxYZgUDH4ejG QgwQ== X-Gm-Message-State: ANoB5plNIVA/59I+T3GfuGBw1ZNOnZns69DhKvUUfVrWrPwNxa4Tniv7 YlFym4f/kr+XqUdO9K46/TkeI8zRld6cVdfXf6uFee3RFog= X-Google-Smtp-Source: AA0mqf44ygAGHYP5Jbg4E5sDcg+Sn5XPvhShiL2yWPtjuPRGunDK9SCLh1THkSKId3HsMq5WTrSpIuEJ41VtsdVyPzE= X-Received: by 2002:a05:6102:3d98:b0:3ad:24a7:63fa with SMTP id h24-20020a0561023d9800b003ad24a763famr46960826vsv.51.1670891603843; Mon, 12 Dec 2022 16:33:23 -0800 (PST) MIME-Version: 1.0 References: <46fcb939-0ed9-4b51-959d-67339181e3e3@app.fastmail.com> <20221210113214.GV27622@tarpaulin.shahaf.local2> <79df64ce-17e7-45e8-833f-f975c97f7797@app.fastmail.com> In-Reply-To: <79df64ce-17e7-45e8-833f-f975c97f7797@app.fastmail.com> From: Philippe Altherr Date: Tue, 13 Dec 2022 01:33:12 +0100 Message-ID: Subject: Re: [PATCH] NEWS item about the ERR_EXIT fixes To: =?UTF-8?Q?Lawrence_Vel=C3=A1zquez?= Cc: Daniel Shahaf , zsh-workers@zsh.org Content-Type: multipart/alternative; boundary="000000000000815fee05efaac4ba" X-Seq: 51199 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: --000000000000815fee05efaac4ba Content-Type: text/plain; charset="UTF-8" > > >> + - Function calls, anonymous functions, and the `eval`, `.`, and > >> + `source` commands no longer propagate ERR_EXIT suppression. > > > > This kind of suggests that these constructs always propagated the > > suppression, which isn't the case, but the exact circumstances look too > > complex to explain. Maybe replace "no longer" with "now never". > What were the circumstances under which they previously propagated > suppression? This is now explained in my new patch proposal (see new thread). I admit that I don't fully understand what this commit did, so I > more or less copied the entry Bart added to ChangeLog: > * Philippe Altherr: 51071: Src/exec.c, Test/C03traps.ztst: fix > ERR_RETURN when a function using && / || is called within another > statement using && / || > That's not accurate either, then? That's just a bit less definitive/precise than your formulation. Enough so that it can be qualified as "not wrong" ;-) My new patch proposal describes the exact circumstances, which unfortunately are rather convoluted. Shouldn't this define the term "suppresses"? It's not used in > the documentation of ERR_EXIT. > Is the option suppressed for the function call or the result of the > anonymous function, or /within/ the called function or anonymous > function? [...] These are all valid questions. I think that they are all addressed by my two new patch proposals. The documentation addresses some but not all of the special cases > and weirdness of ERR_EXIT. I figured that fixing that was out of > scope here, but this might actually be a good time to remedy the > omissions. That way NEWS and README don't have to waste a bunch > of space explaining aspects of ERR_EXIT that should be in the > documentation anyway. Better documentation of ERR_EXIT makes it indeed easier to explain what changed. I took that approach in my two new patch proposals. This is only incidentally true. The documentation omits many details > about ERR_EXIT's special cases, so your changes largely fall between > the lines (so to speak). That was my point. The current documentation is so shallow that it fits both the state before and after my patches. So it could remain as is without being more or less wrong than before. But of course that doesn't avoid the need of documenting what changed because some users may have started to depend on the previous behavior. My updated patch for NEWS and README now describes in detail all the changes. And my patch for the ERR_EXIT and ERR_RETURN documentation adds enough details that it would no longer be compatible with the state before my patches. Philippe --000000000000815fee05efaac4ba Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
>> + =C2=A0- Function calls, anonymous functions, and the = `eval`, `.`, and
>> + =C2=A0 =C2=A0`source` commands no longer pro= pagate ERR_EXIT suppression.
>
> This kind of suggests that the= se constructs always propagated the
> suppression, which isn't th= e case, but the exact circumstances look too
> complex to explain. Ma= ybe replace "no longer" with "now never".
<= 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">
What were the circumstances under = which they previously propagated
suppression?

This is now explained in my new patch proposal (see new thread).

I admit t= hat I don't fully understand what this commit did, so I
more or less= copied the entry Bart added to ChangeLog:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 * Philippe Altherr: = 51071: Src/exec.c, Test/C03traps.ztst: fix
=C2=A0 =C2=A0 =C2=A0 =C2=A0 E= RR_RETURN when a function using && / || is called within another=C2=A0 =C2=A0 =C2=A0 =C2=A0 statement using && / ||

That's not accurate either, the= n?

That's just a bit less definitive/pr= ecise than your formulation. Enough so that it can be qualified as "no= t wrong" ;-)

My new patch proposal desc= ribes the exact circumstances, which unfortunately=C2=A0are rather convolut= ed.

Shouldn't this define the term "suppresses"?=C2=A0 It'= s not used in
the documentation of ERR_EXIT.

Is the option suppressed for the function = call or the result of the
anonymous function, or /within/ the called fun= ction or anonymous
function?
=C2=A0
[...]=C2=A0

These are all vali= d questions. I think that they are all addressed by my two new patch propos= als.

= The documentation addresses some but not all of the special cases
and we= irdness of ERR_EXIT.=C2=A0 I figured that fixing that was out of
scope h= ere, but this might actually be a good time to remedy the
omissions.=C2= =A0 That way NEWS and README don't have to waste a bunch
of space ex= plaining aspects of ERR_EXIT that should be in the
documentation anyway.=

Better documentation of=C2=A0ERR_EXI= T makes it indeed easier to explain what changed. I took that approach in m= y two new patch proposals.

This is only incidentally true.=C2=A0 The documentati= on omits many details
about ERR_EXIT's special cases, so your change= s largely fall between
the lines (so to speak).

That was my point. The current documentation is so shallow that it = fits both the state before and after my patches. So it could remain as is w= ithout being more or less wrong than before. But of course that doesn't= avoid the need of documenting what changed because some users may have sta= rted to depend on the previous behavior. My updated patch for NEWS and READ= ME now describes in detail all the changes. And my patch for the ERR_EXIT a= nd ERR_RETURN documentation adds enough details that it would no longer be = compatible with the state before my patches.

Phili= ppe

--000000000000815fee05efaac4ba--