Path: csiph.com!goblin2!goblin1!goblin.stu.neva.ru!usenet.stanford.edu!not-for-mail
From: Greg Wooledge <wooledg@eeg.ccf.org>
Newsgroups: gnu.bash.bug
Subject: Re: process substitution error handling
Date: Thu, 6 Aug 2020 08:24:18 -0400
Lines: 30
Approved: bug-bash@gnu.org
Message-ID: <mailman.983.1596716690.2739.bug-bash@gnu.org>
References: <20200420051508.GA2359844@zx2c4.com> <7496b183-2db3-6c03-6074-928adcd08f45@case.edu> <CAHmME9pzOY_0EJ69y9wt6r-Jh3frZpV8XdFC6zG5EOkZ99h-1A@mail.gmail.com> <CAH7i3LorhQnvpd0YvTcHsuHM4=v6kTQ+Z8Yf+L43AT1V3zKOFg@mail.gmail.com> <CAHmME9pUd51YvaRWD6az8XgJ=EFw+v+t6xdkBOUx=jqKnH1kbw@mail.gmail.com> <20200806122418.GW22833@eeg.ccf.org>
NNTP-Posting-Host: lists.gnu.org
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-Trace: usenet.stanford.edu 1596716691 29929 209.51.188.17 (6 Aug 2020 12:24:51 GMT)
X-Complaints-To: action@cs.stanford.edu
To: bug-bash@gnu.org
Envelope-to: bug-bash@gnu.org
Mail-Followup-To: bug-bash@gnu.org
Content-Disposition: inline
In-Reply-To: <CAHmME9pUd51YvaRWD6az8XgJ=EFw+v+t6xdkBOUx=jqKnH1kbw@mail.gmail.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Received-SPF: none client-ip=139.137.100.1; envelope-from=wooledg@eeg.ccf.org; helo=mail.eeg.ccf.org
X-detected-operating-system: by eggs.gnu.org: First seen = 2020/08/06 08:24:18
X-ACL-Warn: Detected OS   = Linux 2.2.x-3.x [generic] [fuzzy]
X-Spam_score_int: -8
X-Spam_score: -0.9
X-Spam_bar: /
X-Spam_report: (-0.9 / 5.0 requ) BAYES_00=-1.9, KHOP_HELO_FCRDNS=1, SPF_HELO_NONE=0.001, SPF_NONE=0.001 autolearn=no autolearn_force=no
X-Spam_action: no action
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: <20200806122418.GW22833@eeg.ccf.org>
X-Mailman-Original-References: <20200420051508.GA2359844@zx2c4.com> <7496b183-2db3-6c03-6074-928adcd08f45@case.edu> <CAHmME9pzOY_0EJ69y9wt6r-Jh3frZpV8XdFC6zG5EOkZ99h-1A@mail.gmail.com> <CAH7i3LorhQnvpd0YvTcHsuHM4=v6kTQ+Z8Yf+L43AT1V3zKOFg@mail.gmail.com> <CAHmME9pUd51YvaRWD6az8XgJ=EFw+v+t6xdkBOUx=jqKnH1kbw@mail.gmail.com>
Xref: csiph.com gnu.bash.bug:16705

On Thu, Aug 06, 2020 at 02:14:07PM +0200, Jason A. Donenfeld wrote:
> On Thu, Aug 6, 2020 at 1:15 PM Oğuz <oguzismailuysal@gmail.com> wrote:
> >     set -e o substfail
> >     : <(sleep 10; exit 1)
> >     foo
> >
> > Say that `foo' is a command that takes longer than ten seconds to complete, how would you expect the shell to behave here? Should it interrupt `foo' or wait for its termination and exit then? Or do something else?
> 
> It's likely simpler to check after foo, since bash can just ask "are
> any of the process substitution processes that I was wait(2)ing on in
> exited state with non zero return?", which just involves looking in a
> little list titled exited_with_error_process_subst for being non-null.

So, in a script like this:

set -e -o failevenharder
: <(sleep 1; false)
cmd1
cmd2
cmd3
cmd4

They're asking that the script abort at some unpredictable point during
the sequence of commands cmd1, cmd2, cmd3, cmd4 whenever the process
substitution happens to terminate?

I'm almost tempted to get behind that just to help the set -e users
reach the point of terminal absurdity even faster.  The wreckage should
be hilarious.