Path: csiph.com!tncsrv06.tnetconsulting.net!news.snarked.org!news.linkpendium.com!news.linkpendium.com!panix!usenet.stanford.edu!not-for-mail
From: Shaun Crampton <shaun@tigera.io>
Newsgroups: gnu.bash.bug
Subject: Re: set -e ignored in subshell if part of command list
Date: Wed, 13 Nov 2019 15:59:22 +0000
Lines: 67
Approved: bug-bash@gnu.org
Message-ID: <mailman.1348.1573660778.13325.bug-bash@gnu.org>
References: <CAMhR0U1fzAvXMVZacEYf9yAPwgq_6Gz5C-99dj6xt=9pQMtX8Q@mail.gmail.com> <13040a55-507d-e072-e827-be7c33be968f@case.edu> <CAMhR0U3yqJ5N-gMCOK7SspOJcdcOCEtu_+cV3=zUgr7fJmkRRQ@mail.gmail.com>
NNTP-Posting-Host: lists.gnu.org
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Cc: bug-bash@gnu.org
To: chet.ramey@case.edu
Envelope-to: bug-bash@gnu.org
In-Reply-To: <13040a55-507d-e072-e827-be7c33be968f@case.edu>
Precedence: list
Xref: csiph.com gnu.bash.bug:15671

But the commands in the subshell execute inside a different shell
execution context so they shouldn't have
their own set -e context (Section 2.12)?

I don't see where the spec says that the subshell has to inherit the
and/or list-ness of the
parent context.  Section 2.12 doesn't mention that as being one of the
things that a subshell inherits
(and unless I'm missing a good use-case, it seems like a pretty
useless thing to inherit in a subshell
or a function that happens to be called on the LHS of an and/or).


On Wed, Nov 13, 2019 at 3:07 PM Chet Ramey <chet.ramey@case.edu> wrote:
>
> On 11/13/19 5:24 AM, Shaun Crampton wrote:
>
> > Bash Version: 5.0
> > Patch Level: 3
> > Release Status: release
> >
> > Description:
> >         I was trying to get a function to return early if a command
> > fails by putting
> >         the body of the function in a subshell and using set -e inside
> > the subshell.
> >         If I run a subshell on its own, this works, but when I try to combine it
> >         into a larger program, the set -e gets ignored.
> >
> > Repeat-By:
> >          Managed to boil it down to this smaller example:
> >
> >          # On its own, subshell behaves as expected:
> >          $ ( set -ex; false; echo here )
> >          + false
> >
> >          # In a list, behaviour changes, "echo here" gets executed:
> >          $ ( set -ex; false; echo here ) && echo there
> >          + false
> >          + echo here
> >          here
> >          there
>
> The subshell command is part of an and-or list, so the -e is ignored for
> that command:
>
> "The -e setting shall be ignored when executing the compound list following
> the while, until, if, or elif reserved word, a pipeline beginning with the
> ! reserved word, or any command of an AND-OR list other than the last."
>
> (from
> https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_25_03)
>
> The subshell inherits this state (being part of an and-or list) from its
> parent.
>
> >
> >         # If the subshell is executed in the background, it works
> >         $ ( set -e; false; echo here ) & pid=$!; wait $pid && echo there
>
> In this command, the subshell is not part of an and-or list.
>
> --
> ``The lyf so short, the craft so long to lerne.'' - Chaucer
>                  ``Ars longa, vita brevis'' - Hippocrates
> Chet Ramey, UTech, CWRU    chet@case.edu    http://tiswww.cwru.edu/~chet/