Subject: Re: [PATCH 02/12] t: prepare `test_must_fail ()` for `set -e`

From: Jeff King <[email-masked]>
Date: Thu, 16 Apr 2026 01:40:38 -0400

On Wed, Apr 15, 2026 at 08:58:40AM +0200, Patrick Steinhardt wrote:

> > "set" is described in
> > 
> >   https://pubs.opengroup.org/onlinepubs/9799919799/utilities/V3_chap02.html#tag_19_26
> > 
> > and the description for "-e" does not even talk about any function.
> > The application usage notes associated with the "set" gives this
> > 
> >     Application writers should avoid relying on set -e within
> >     functions. For example, in the following script:
> > 
> >     set -e
> >     start() {
> >         some_server
> >         echo some_server started successfully
> >     }
> >     start || echo >&2 some_server failed
> > 
> >     the -e setting is ignored within the function body (because the
> >     function is a command in an AND-OR list other than the
> >     last). Therefore, if some_server fails, the function carries on to
> >     echo "some_server started successfully", and the exit status of the
> >     function is zero (which means "some_server failed" is not output).
> > 
> > which greatly helps.
> 
> The funny thing is that I discovered shells where this is not the case,
> and `set -e` _does_ extend into functions.

It should extend into functions for all shells. It is just that the
suppression via "if" (or "&&", "||", etc) is counter-intuitive because
it applies to individual commands within the function, not just the
return value of the function as a whole.

So if you have seen shells where "set -e" is respected within a function
even when that function is part of a conditional, that would be
noteworthy. But mostly only for our own curiosity at this point, I
think, as we'd be restricting the set of shells we'd even try to use
"set -e" with.

-Peff