Path: csiph.com!3.us.feeder.erje.net!feeder.erje.net!news.snarked.org!news.linkpendium.com!news.linkpendium.com!panix!usenet.stanford.edu!not-for-mail
From: John W <jwdevel@gmail.com>
Newsgroups: gnu.bash.bug
Subject: Re: Bug? `set -e` inside functions inside `$(...)`
Date: Thu, 3 Oct 2019 17:58:02 -0700
Lines: 57
Approved: bug-bash@gnu.org
Message-ID: <mailman.934.1570163406.2651.bug-bash@gnu.org>
References: <CADO30sqtGh+O54c0pLic-8YA00VG244gcRY8x8XFv8yHNby5yA@mail.gmail.com> <CADO30spotrQHiTWfKFngTPERSypRz3PgJRh+UA1EKv_D=qGiBQ@mail.gmail.com>
NNTP-Posting-Host: lists.gnu.org
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
To: bug-bash@gnu.org
Envelope-to: bug-bash@gnu.org
In-Reply-To: <CADO30sqtGh+O54c0pLic-8YA00VG244gcRY8x8XFv8yHNby5yA@mail.gmail.com>
Precedence: list
Xref: csiph.com gnu.bash.bug:15471

Ah, got it sorted out.

Not a bug, of course (:

Bash, when not in posix mode, clears the '-e' flag in subshell environments.

On 10/3/19, John W <jwdevel@gmail.com> wrote:
> I'm seeing some strange behavior w/regard to `set -e` when invoking a
> shell function through a `$(...)` construct.
>
> I can't tell if it's a bug or not; the manpage doesn't really mention
> $() specially with regard to `set -e`, that I have found.
>
> I made a SO post with a bunch of details here:
> https://stackoverflow.com/questions/58228383/bash-set-e-reset-inside-functions-when-run-via
>
> But here's my small repro program:
>
>     #!/usr/bin/env bash
>
>     echo "Initial:    $-"
>     set -eu
>     echo "After set:  $-"
>
>     function foo() {
>         echo "Inside foo: $-"
>     }
>     foo
>
>     function bar() {
>         false    # I'd expect this to immediately fail
>         echo "Inside bar: $-"
>     }
>     # When a $(...) construct is involved, 'bar' runs to completion!
>     x=$(bar)
>     echo "We should never get here ... but we do."
>     echo "$x"
>
> For me, this ouputs:
>
>     Initial:    hB
>     After set:  ehuB
>     Inside foo: ehuB
>     We should never get here ... but we do.
>     Inside bar: huB
>
> and it's really the last two lines that confuse me. Why was 'set -e'
> disabled inside of "bar"?
>
> Is this documented behavior, and I missed it?
> Or a bug?
> Or makes sense under some interpretation of things that I'm not grasping?
>
> Thanks for any advice
> -John
>