zsh-workers
 help / color / mirror / code / Atom feed
* [PATCH] NEWS item about the ERR_EXIT fixes
@ 2022-12-08 21:45 Philippe Altherr
  2022-12-09  0:24 ` Bart Schaefer
  0 siblings, 1 reply; 13+ messages in thread
From: Philippe Altherr @ 2022-12-08 21:45 UTC (permalink / raw)
  To: Zsh hackers list


[-- Attachment #1.1: Type: text/plain, Size: 588 bytes --]

Here is the promised NEWS item that documents the ERR_EXIT fixes.
Unfortunately, explaining what changes isn't that easy because only rather
involved cases are affected. I couldn't make it shorter than what is in the
patch. And I still omitted the even more involved case fixed by 51071: fix
ERR_RETURN for functions in conditional statements
<https://github.com/zsh-users/zsh/commit/259f1e944b96715fda25f7ba227da05bdb7e600f>
.

An alternative would be to simply state that a number of ERR_EXIT bugs
affecting only corner cases were fixed, without trying to describe the
cases.

Philippe

[-- Attachment #1.2: Type: text/html, Size: 694 bytes --]

[-- Attachment #2: patch-errexit-fixes-news.txt --]
[-- Type: text/plain, Size: 1397 bytes --]

diff --git a/NEWS b/NEWS
index cdafd1ff5..877a5550b 100644
--- a/NEWS
+++ b/NEWS
@@ -4,6 +4,26 @@ CHANGES FROM PREVIOUS VERSIONS OF ZSH
 
 Note also the list of incompatibilities in the README file.
 
+Changes since 5.9
+-----------------
+
+Fixed several bugs in the implementation of ERR_EXIT. When ERR_EXIT is
+enabled, when any command fails the shell immediately exits, except if
+ERR_EXIT was being suppressed for that command. ERR_EXIT is suppressed
+for commands on the left of && and ||, on the right of !, and in the
+condition of if, while, and until. ERR_EXIT is also suppressed in any
+structured command (if, for, while, until, repeat, case, select,
+always, or a list in braces) whose exit status is the result of a
+failure while ERR_EXIT was being suppressed. Thus, neither "false &&
+true" nor "if true; then false && true; fi" cause an immediate exit.
+However, if these expressions are the body of a function, then a call
+to that function must cause an exit. Until now, Zsh failed to do so
+for the latter. Similarly, it failed to exit if that expression was
+the argument of an eval command or the body of a sourced script.
+Until now, Zsh also failed to suppress ERR_EXIT for negated function
+calls and for always statements. Thus, "func() { true }; ! func" and
+"{ false && true } always { true }" incorrectly caused an exit.
+
 Changes since 5.8.1
 -------------------
 

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH] NEWS item about the ERR_EXIT fixes
  2022-12-08 21:45 [PATCH] NEWS item about the ERR_EXIT fixes Philippe Altherr
@ 2022-12-09  0:24 ` Bart Schaefer
  2022-12-09  6:44   ` Lawrence Velázquez
  0 siblings, 1 reply; 13+ messages in thread
From: Bart Schaefer @ 2022-12-09  0:24 UTC (permalink / raw)
  To: Philippe Altherr; +Cc: Zsh hackers list

On Thu, Dec 8, 2022 at 1:47 PM Philippe Altherr
<philippe.altherr@gmail.com> wrote:
>
> I couldn't make it shorter than what is in the patch.

I think this is fine.  Any opposed?


^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH] NEWS item about the ERR_EXIT fixes
  2022-12-09  0:24 ` Bart Schaefer
@ 2022-12-09  6:44   ` Lawrence Velázquez
  2022-12-09  9:30     ` Philippe Altherr
  2022-12-10 11:32     ` Daniel Shahaf
  0 siblings, 2 replies; 13+ messages in thread
From: Lawrence Velázquez @ 2022-12-09  6:44 UTC (permalink / raw)
  To: Bart Schaefer, Philippe Altherr; +Cc: zsh-workers

On Thu, Dec 8, 2022, at 7:24 PM, Bart Schaefer wrote:
> On Thu, Dec 8, 2022 at 1:47 PM Philippe Altherr
> <philippe.altherr@gmail.com> wrote:
>>
>> I couldn't make it shorter than what is in the patch.
>
> I think this is fine.  Any opposed?

I think it's overly verbose; NEWS doesn't have to explain how
ERR_EXIT works.  Here's a possible alternative:

diff --git a/NEWS b/NEWS
index cdafd1ff5..d8b8687c0 100644
--- a/NEWS
+++ b/NEWS
@@ -4,8 +4,27 @@ CHANGES FROM PREVIOUS VERSIONS OF ZSH
 
 Note also the list of incompatibilities in the README file.
 
-Changes since 5.8.1
--------------------
+Changes since 5.9
+-----------------
+
+The ERR_EXIT option was refined to be more self-consistent and better
+aligned with the POSIX-2017 specification of `set -e`:
+
+  - Prefixing a function call or anonymous function with `!` now
+    suppresses ERR_EXIT.
+
+  - The `always` command now propagates ERR_EXIT suppression, as other
+    complex commands do.
+
+  - Function calls, anonymous functions, and the `eval`, `.`, and
+    `source` commands no longer propagate ERR_EXIT suppression.
+
+The ERR_RETURN option is now suppressed when a function containing
+a compound sublist (`&&` or `||`) is called from within another compound
+sublist.
+
+Changes from 5.8.1 to 5.9
+-------------------------
 
 zsh 5.9 is dedicated to the memory of Sven Guckes, who was, amongst other
 things, a long-time zsh advocate.  For more information, see:
-- 
vq


^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH] NEWS item about the ERR_EXIT fixes
  2022-12-09  6:44   ` Lawrence Velázquez
@ 2022-12-09  9:30     ` Philippe Altherr
  2022-12-09 15:17       ` Mikael Magnusson
  2022-12-10  7:35       ` Lawrence Velázquez
  2022-12-10 11:32     ` Daniel Shahaf
  1 sibling, 2 replies; 13+ messages in thread
From: Philippe Altherr @ 2022-12-09  9:30 UTC (permalink / raw)
  To: Lawrence Velázquez; +Cc: Bart Schaefer, zsh-workers

[-- Attachment #1: Type: text/plain, Size: 1171 bytes --]

>
> I think it's overly verbose; NEWS doesn't have to explain how
> ERR_EXIT works.  Here's a possible alternative:


Overall looks good to me but see comments below.

+  - 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".


> +The ERR_RETURN option is now suppressed when a function containing
> +a compound sublist (`&&` or `||`) is called from within another compound
> +sublist.


 I find this a bit cryptic. It may also give the wrong impression that
functions containing a compound sublist are a special case. And finally,
the same is true for functions called in if/while conditions. Here is an
alternative:

The ERR_RETURN option is now always suppressed on the left of `&&` and `||`
> (now even in commands within functions called from contexts where
> ERR_RETURN is suppressed).


The part in parenthesis gives a hint on what changed but maybe that could
be left out.

Philippe

[-- Attachment #2: Type: text/html, Size: 1972 bytes --]

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH] NEWS item about the ERR_EXIT fixes
  2022-12-09  9:30     ` Philippe Altherr
@ 2022-12-09 15:17       ` Mikael Magnusson
  2022-12-10  7:23         ` Lawrence Velázquez
  2022-12-10  7:35       ` Lawrence Velázquez
  1 sibling, 1 reply; 13+ messages in thread
From: Mikael Magnusson @ 2022-12-09 15:17 UTC (permalink / raw)
  To: Philippe Altherr; +Cc: Lawrence Velázquez, Bart Schaefer, zsh-workers

On 12/9/22, Philippe Altherr <philippe.altherr@gmail.com> wrote:
>>
>> I think it's overly verbose; NEWS doesn't have to explain how
>> ERR_EXIT works.  Here's a possible alternative:
>
>
> Overall looks good to me but see comments below.
>
> +  - 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".
>
>
>> +The ERR_RETURN option is now suppressed when a function containing
>> +a compound sublist (`&&` or `||`) is called from within another compound
>> +sublist.
>
>
>  I find this a bit cryptic. It may also give the wrong impression that
> functions containing a compound sublist are a special case. And finally,
> the same is true for functions called in if/while conditions. Here is an
> alternative:
>
> The ERR_RETURN option is now always suppressed on the left of `&&` and `||`
>> (now even in commands within functions called from contexts where
>> ERR_RETURN is suppressed).
>
>
> The part in parenthesis gives a hint on what changed but maybe that could
> be left out.

As the context for the first hunk in the original patch says, README
has a longer section about incompatibilities already, perhaps any more
detailed descriptions as to what changed can be appended there?

-- 
Mikael Magnusson


^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH] NEWS item about the ERR_EXIT fixes
  2022-12-09 15:17       ` Mikael Magnusson
@ 2022-12-10  7:23         ` Lawrence Velázquez
  0 siblings, 0 replies; 13+ messages in thread
From: Lawrence Velázquez @ 2022-12-10  7:23 UTC (permalink / raw)
  To: Mikael Magnusson, Philippe Altherr; +Cc: Bart Schaefer, zsh-workers

On Fri, Dec 9, 2022, at 10:17 AM, Mikael Magnusson wrote:
> As the context for the first hunk in the original patch says, README
> has a longer section about incompatibilities already, perhaps any more
> detailed descriptions as to what changed can be appended there?

Yeah, I had considered including some examples in README but decided
to put it off and go to sleep instead :)

-- 
vq


^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH] NEWS item about the ERR_EXIT fixes
  2022-12-09  9:30     ` Philippe Altherr
  2022-12-09 15:17       ` Mikael Magnusson
@ 2022-12-10  7:35       ` Lawrence Velázquez
  1 sibling, 0 replies; 13+ messages in thread
From: Lawrence Velázquez @ 2022-12-10  7:35 UTC (permalink / raw)
  To: Philippe Altherr; +Cc: Bart Schaefer, zsh-workers

On Fri, Dec 9, 2022, at 4:30 AM, Philippe Altherr wrote:
>> +  - 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?

>> +The ERR_RETURN option is now suppressed when a function containing
>> +a compound sublist (`&&` or `||`) is called from within another compound
>> +sublist.
>
>  I find this a bit cryptic. It may also give the wrong impression that 
> functions containing a compound sublist are a special case. And 
> finally, the same is true for functions called in if/while conditions.

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?

-- 
vq


^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH] NEWS item about the ERR_EXIT fixes
  2022-12-09  6:44   ` Lawrence Velázquez
  2022-12-09  9:30     ` Philippe Altherr
@ 2022-12-10 11:32     ` Daniel Shahaf
  2022-12-10 13:49       ` Philippe Altherr
  2022-12-11  3:23       ` Lawrence Velázquez
  1 sibling, 2 replies; 13+ messages in thread
From: Daniel Shahaf @ 2022-12-10 11:32 UTC (permalink / raw)
  To: zsh-workers; +Cc: Philippe Altherr

Lawrence Velázquez wrote on Fri, Dec 09, 2022 at 01:44:44 -0500:
> On Thu, Dec 8, 2022, at 7:24 PM, Bart Schaefer wrote:
> > On Thu, Dec 8, 2022 at 1:47 PM Philippe Altherr
> > <philippe.altherr@gmail.com> wrote:
> >>
> >> I couldn't make it shorter than what is in the patch.
> >
> > I think this is fine.  Any opposed?
> 
> I think it's overly verbose; NEWS doesn't have to explain how
> ERR_EXIT works.  Here's a possible alternative:
> 
> diff --git a/NEWS b/NEWS
> index cdafd1ff5..d8b8687c0 100644
> --- a/NEWS
> +++ b/NEWS
> @@ -4,8 +4,27 @@ CHANGES FROM PREVIOUS VERSIONS OF ZSH
>  
>  Note also the list of incompatibilities in the README file.
>  
> -Changes since 5.8.1
> --------------------
> +Changes since 5.9
> +-----------------
> +
> +The ERR_EXIT option was refined to be more self-consistent and better
> +aligned with the POSIX-2017 specification of `set -e`:
> +
> +  - Prefixing a function call or anonymous function with `!` now
> +    suppresses ERR_EXIT.

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?

What's the behaviour of ERR_EXIT on «! foo» when foo isn't a named or
anonymous function?  I.e., does the change make function calls an
exception, or does it make them /no longer/ an exception?  I think the
text should answer this.

> +
> +  - The `always` command now propagates ERR_EXIT suppression, as other
> +    complex commands do.
> +

Shouldn't this define the term "propagates"?  It's not used in
the documentation of ERR_EXIT.

> +  - Function calls, anonymous functions, and the `eval`, `.`, and
> +    `source` commands no longer propagate ERR_EXIT suppression.

s/commands/builtins/

> +
> +The ERR_RETURN option is now suppressed when a function containing
> +a compound sublist (`&&` or `||`) is called from within another compound
> +sublist.
> +

Does suppression happen for the result of the call, or within the
callee?

What exactly are the conditions whereupon suppression happens?  As
written, the text implies that suppression happens in
.
    FWaCL() { …; if false; then : && :; fi; … }
    false || FWaCL
.
regardless of the values of the ellipses; is that the intended meaning?

As you mentioned downthread, please add examples of affected cases (and,
if needed, of unaffected cases too).  Doc/Zsh/ can be updated as well,
if needed (this is discussed on the 51089 thread).

Proposed text (possibly wrong, do not use it without checking for
correctness and omissions):

    The ERR_EXIT option no longer applies to the result of commands
    of the form '! foo' regardless of what 'foo' is.  Previously, the
    option did take effect if 'foo' were a function call or an anonymous
    function.  Example:
    .
	setopt ERR_EXIT
        f() { false }
	g() { ! f; echo This will be printed in 5.10 but was not printed in 5.9 }

    The ERR_EXIT option now applies to the result of an 'always'
    block.  This aligns 'always' with other complex commands.
    Example:
    .
	setopt ERR_EXIT
        { false } always { echo This would be printed by either 5.9 and 5.10 }
	echo This would only be printed by 5.10 and newer
    # I'm saying "complex" rather than "compound" because that's the
    # term the manual uses.

    The ERR_EXIT option now applies to the results of function calls,
    anonymous functions, and the `eval`, `.`, and `source` builtins.
    Example:
    .
        setopt ERR_EXIT
	f() { false; }
	f
	echo This was printed under 5.9 but will not be printed by 5.10

    The ERR_RETURN option now applies within a function even if the
    return code of the function itself would not trigger ERR_RETURN
    behaviour from the function's caller (e.g., because the function
    call is on the left-hand side of an "&&" or "||").  Example:
    .
        setopt ERR_RETURN
	f() { false; echo This was printed under 5.9 but will not be printed under 5.10 }
	g() { f || true }

Cheers,

Daniel

P.S. Personally, I'd have preferred it if the four commits with "51001:"
at the start of their log message had something unique there, e.g.,
"51001/{1..4}", as per precedent (e.g., zsh-5.8-433-ga23f19bfb).
Rationale: so anyone doing «git log --grep='^51001'» would know, from
the first log message they see, that several commits match the grep,
rather than just one as might be assumed.

> +Changes from 5.8.1 to 5.9
> +-------------------------
>  
>  zsh 5.9 is dedicated to the memory of Sven Guckes, who was, amongst other
>  things, a long-time zsh advocate.  For more information, see:
> -- 
> vq
> 


^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH] NEWS item about the ERR_EXIT fixes
  2022-12-10 11:32     ` Daniel Shahaf
@ 2022-12-10 13:49       ` Philippe Altherr
  2022-12-11  3:32         ` Lawrence Velázquez
  2022-12-11  3:23       ` Lawrence Velázquez
  1 sibling, 1 reply; 13+ messages in thread
From: Philippe Altherr @ 2022-12-10 13:49 UTC (permalink / raw)
  To: Daniel Shahaf; +Cc: zsh-workers

[-- Attachment #1: Type: text/plain, Size: 829 bytes --]

Just a quick reply. I will prepare an updated patch that includes a short
description in NEWS (mainly an updated version of Lawrence's proposal) and
a longer one with examples in README. Once it's ready (probably only
tomorrow), I will check again here whether there are still questions not
yet answered by the updated patch.

Afaik, Zsh intends to be compatible with the POSIX "set -e" specification
<https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#set>.
If that is indeed the case, then all the patches can be seen as bug fixes.
So no Zsh doc changes are required (or at least not because of these
patches). The patches also only affect corner cases, which are quite a bit
more complicated than Daniel's examples. None of Daniel's examples are
affected; they all keep behaving the same way.

Philippe

[-- Attachment #2: Type: text/html, Size: 978 bytes --]

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH] NEWS item about the ERR_EXIT fixes
  2022-12-10 11:32     ` Daniel Shahaf
  2022-12-10 13:49       ` Philippe Altherr
@ 2022-12-11  3:23       ` Lawrence Velázquez
  1 sibling, 0 replies; 13+ messages in thread
From: Lawrence Velázquez @ 2022-12-11  3:23 UTC (permalink / raw)
  To: Daniel Shahaf, zsh-workers; +Cc: Philippe Altherr

On Sat, Dec 10, 2022, at 6:32 AM, Daniel Shahaf wrote:
> Shouldn't this define the term "suppresses"?  It's not used in
> the documentation of ERR_EXIT.
>
> [...]
>
> Shouldn't this define the term "propagates"?  It's not used in
> the documentation of ERR_EXIT.
>
> [...]
>
> Doc/Zsh/ can be updated as well,
> if needed (this is discussed on the 51089 thread).

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.

-- 
vq


^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH] NEWS item about the ERR_EXIT fixes
  2022-12-10 13:49       ` Philippe Altherr
@ 2022-12-11  3:32         ` Lawrence Velázquez
  2022-12-13  0:33           ` Philippe Altherr
  0 siblings, 1 reply; 13+ messages in thread
From: Lawrence Velázquez @ 2022-12-11  3:32 UTC (permalink / raw)
  To: Philippe Altherr, Daniel Shahaf; +Cc: zsh-workers

On Sat, Dec 10, 2022, at 8:49 AM, Philippe Altherr wrote:

> Afaik, Zsh intends to be compatible with the POSIX "set -e" 
> specification 

On what are you basing this assertion?

> If that is indeed the case, then all the patches can be seen as bug 
> fixes.

I don't agree.  The documentation barely says anything about any
of the behaviors you modified, and zsh is not a POSIX-compatible
shell, so it's entirely reasonable for users to have accepted the
previous behavior as intentional.

> So no Zsh doc changes are required (or at least not because of 
> these patches).

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).

-- 
vq


^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH] NEWS item about the ERR_EXIT fixes
  2022-12-11  3:32         ` Lawrence Velázquez
@ 2022-12-13  0:33           ` Philippe Altherr
  2022-12-13  3:05             ` Daniel Shahaf
  0 siblings, 1 reply; 13+ messages in thread
From: Philippe Altherr @ 2022-12-13  0:33 UTC (permalink / raw)
  To: Lawrence Velázquez; +Cc: Daniel Shahaf, zsh-workers

[-- Attachment #1: Type: text/plain, Size: 2671 bytes --]

>
> >> +  - 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

[-- Attachment #2: Type: text/html, Size: 5128 bytes --]

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH] NEWS item about the ERR_EXIT fixes
  2022-12-13  0:33           ` Philippe Altherr
@ 2022-12-13  3:05             ` Daniel Shahaf
  0 siblings, 0 replies; 13+ messages in thread
From: Daniel Shahaf @ 2022-12-13  3:05 UTC (permalink / raw)
  To: zsh-workers

>> 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.

Indeed.  The patches LGTM.  Thanks :)


^ permalink raw reply	[flat|nested] 13+ messages in thread

end of thread, other threads:[~2022-12-13  3:06 UTC | newest]

Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-12-08 21:45 [PATCH] NEWS item about the ERR_EXIT fixes Philippe Altherr
2022-12-09  0:24 ` Bart Schaefer
2022-12-09  6:44   ` Lawrence Velázquez
2022-12-09  9:30     ` Philippe Altherr
2022-12-09 15:17       ` Mikael Magnusson
2022-12-10  7:23         ` Lawrence Velázquez
2022-12-10  7:35       ` Lawrence Velázquez
2022-12-10 11:32     ` Daniel Shahaf
2022-12-10 13:49       ` Philippe Altherr
2022-12-11  3:32         ` Lawrence Velázquez
2022-12-13  0:33           ` Philippe Altherr
2022-12-13  3:05             ` Daniel Shahaf
2022-12-11  3:23       ` Lawrence Velázquez

Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).