Path: csiph.com!weretis.net!feeder6.news.weretis.net!news.linkpendium.com!news.linkpendium.com!panix!usenet.stanford.edu!not-for-mail
From: =?ISO-8859-1?Q?=C1ngel?= <angel@debian.16bits.net>
Newsgroups: gnu.bash.bug
Subject: Re: set -e ignored in subshell if part of command list
Date: Fri, 15 Nov 2019 00:02:21 +0100
Lines: 51
Approved: bug-bash@gnu.org
Message-ID: <mailman.1500.1573772923.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> <d3c4201b-85d4-eb53-fbd7-ef389f6f7f03@case.edu> <1573772541.924.11.camel@debian.16bits.net>
NNTP-Posting-Host: lists.gnu.org
Mime-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-15"
Content-Transfer-Encoding: quoted-printable
X-Trace: usenet.stanford.edu 1573772924 675 209.51.188.17 (14 Nov 2019 23:08:44 GMT)
X-Complaints-To: action@cs.stanford.edu
To: bug-bash@gnu.org
Envelope-to: bug-bash@gnu.org
In-Reply-To: <d3c4201b-85d4-eb53-fbd7-ef389f6f7f03@case.edu>
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy]
X-Received-From: 199.195.249.9
X-Mailman-Approved-At: Thu, 14 Nov 2019 18:08:42 -0500
X-BeenThere: bug-bash@gnu.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Bug reports for the GNU Bourne Again SHell <bug-bash.gnu.org>
List-Unsubscribe: <https://lists.gnu.org/mailman/options/bug-bash>, <mailto:bug-bash-request@gnu.org?subject=unsubscribe>
List-Archive: <https://lists.gnu.org/archive/html/bug-bash>
List-Post: <mailto:bug-bash@gnu.org>
List-Help: <mailto:bug-bash-request@gnu.org?subject=help>
List-Subscribe: <https://lists.gnu.org/mailman/listinfo/bug-bash>, <mailto:bug-bash-request@gnu.org?subject=subscribe>
X-Mailman-Original-Message-ID: <1573772541.924.11.camel@debian.16bits.net>
X-Mailman-Original-References: <CAMhR0U1fzAvXMVZacEYf9yAPwgq_6Gz5C-99dj6xt=9pQMtX8Q@mail.gmail.com> <13040a55-507d-e072-e827-be7c33be968f@case.edu> <CAMhR0U3yqJ5N-gMCOK7SspOJcdcOCEtu_+cV3=zUgr7fJmkRRQ@mail.gmail.com> <d3c4201b-85d4-eb53-fbd7-ef389f6f7f03@case.edu>
Xref: csiph.com gnu.bash.bug:15597

On 2019-11-13 at 11:30 -0500, Chet Ramey wrote:
> On 11/13/19 10:59 AM, Shaun Crampton wrote:
> > 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)?
>=20
> Why? That section says the only thing that changes in the subshell=20
> environment is signal dispositions.
>=20
> In fact, the example in the set builtin description explicitly assumes
> the subshell inherits the errexit setting. The only thing the standard
> requires here is that setting -e in the subshell doesn't change the
> parent's setting.
>=20
> But that's not exactly the point. The shell is "executing any command of =
an
> AND-OR list other than the last" so errexit is ignored.


I would say that the confusing part is that the behavior of the subshell
is dependant on *where* it is being executed in the parent.

In general terms, I would expect
  ( <code> )
to be roughly equivalent to=20
  bash -c "<code>"

i.e. <code> being executed on its own context and unable to affect the
parent

but the provided case shows that=20
  ( set -e; false; echo here ) && echo bar
behaves differently than
  bash -c "set -e; false; echo here" && echo there

since the initial subshell has an advanced knowledge that there will be
a later command joined by an and.

And the fact that reversing the order
  echo hello && ( set -e; false; echo here )

gives a different result, as it is now the *final* element of the &&
list.

The joys of set -e
https://mywiki.wooledge.org/BashFAQ/105, already mentioned in the thread
gives a =ABfunny=BB read of these things.

Kind regards