Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > gnu.bash.bug > #16711

Re: process substitution error handling

Path csiph.com!goblin3!goblin1!goblin.stu.neva.ru!usenet.stanford.edu!not-for-mail
From "" <kfm@plushkava.net>
Newsgroups gnu.bash.bug
Subject Re: process substitution error handling
Date Thu, 6 Aug 2020 14:15:40 +0100
Lines 62
Approved bug-bash@gnu.org
Message-ID <mailman.994.1596719749.2739.bug-bash@gnu.org> (permalink)
References <20200420051508.GA2359844@zx2c4.com> <7496b183-2db3-6c03-6074-928adcd08f45@case.edu> <CAHmME9pzOY_0EJ69y9wt6r-Jh3frZpV8XdFC6zG5EOkZ99h-1A@mail.gmail.com> <e0a56db4-6444-5dde-3fdc-e3237e669cc6@archlinux.org> <8a54cb1e-af78-f79f-6d73-6a235d707207@plushkava.net>
NNTP-Posting-Host lists.gnu.org
Mime-Version 1.0
Content-Type text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding 7bit
X-Trace usenet.stanford.edu 1596719749 32110 209.51.188.17 (6 Aug 2020 13:15:49 GMT)
X-Complaints-To action@cs.stanford.edu
To bug-bash@gnu.org
Envelope-to bug-bash@gnu.org
DKIM-Signature v=1; a=rsa-sha256; c=relaxed/relaxed; d=plushkava.net; h=subject:to:references:from:message-id:date:mime-version :in-reply-to:content-type:content-transfer-encoding; s=fm3; bh=7 DqZqE5r9DTQ3o1KNQExnmeFYCONSwZ5d7pZnVcSjIc=; b=lFdNoBitr6AFktAFL 3l1qtU/EzPqGdNa6JZc/RRzOBUmIJ22YAvGZRw9WH+WaHqhVw0+ZFbf7iPHNxIdI qn5c4niUVbH1scNakKknc2Hu5KSFjcm73fpRPuVIX1lrHrZcaapj6oTMXpu7xKWT WBXyZN0a9cxtKdzur+Z+L8SJB044LQx3Q1e91pZZEVMAm5XusxkudPg4J4HSmU4k MupxhgGqw6NS+ZggiWIaYQkPqSZz6tTWJXqWi7yvkxknFB0vbwqYs1Xcuqy53ZJg t+rZ5zqNGg9wd0HknEclk0sJ2UQVSv8bWBg32rB8HGlZl0OAlA8Y99xVHCwvmX+Q BlapQ==
DKIM-Signature v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=7DqZqE5r9DTQ3o1KNQExnmeFYCONSwZ5d7pZnVcSj Ic=; b=JZAkd3gP3HsRIUGsX65ysOpC5//RS3C5z0waPKrc0FRZ7qQjBCud4ab7G 7E+u7884hM+4guA1CJMeCNr1MmvjCTEysE0m0hlcI5Sf134oQt/m6NvmUTixpZXk KErSxFEbUAe/NCVoQI93wr//yY/4wLgLSoJSeQld90p30dTpVNeM/zIXbtzzHl62 X9EYH6s1hh93CdJKdLrZAwVrxi0Anfu9BBR/nKdxjuIC2C8r2jxQyht+vEqYGiKj DQ0Bliu9S3nevU+UmE8QwSNIcfxeW6lwhjn4A5Lnwg4RgmeVlHWYbaiABbxw/z8g MOJAYRixWv+/W5EXmjz+cDi5RAPzQ==
X-ME-Sender <xms:fgIsX94qD4-UBH5pJ3yMBv506U-yBUPdFChyG7Do9Qkjy4DSmhacBg>
X-ME-Proxy-Cause gggruggvucftvghtrhhoucdtuddrgeduiedrkedtgdeigecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecuogfgmhhpthihtehlihgrshculddvtddmnecujfgurh epuffvfhfhkffffgggjggtgfesthejredttdefjeenucfhrhhomhepfddfuceokhhfmhes phhluhhshhhkrghvrgdrnhgvtheqnecuggftrfgrthhtvghrnhepuefghfekfeeiffeftd egfeefudffueetheefleeggedvheeitdegtdejtefhhfelnecuffhomhgrihhnpeifohho lhgvughgvgdrohhrghenucfkphepudelfedrudefkedrvddukedrudeltdenucevlhhush htvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehkfhhmsehplhhushhh khgrvhgrrdhnvght
X-ME-Proxy <xmx:fgIsX67QltrJV7QWxsg7POyzh28TlOrf9qWrwbqfGVN6B795S2sp9Q> <xmx:fgIsX0eGe820ahGl1vpD6KRXdjvSXaSBdNxC0FubDAzFZypteArzHg> <xmx:fgIsX2JikxgQ5QJ1xe8o1b5cdm-a6_8IvXNSKOJkbt672kxTat1muw> <xmx:fwIsX0aRUNUwvSbz8JbSBIaGHtgFCJX2Ymo_nQ8-yB6SiNi3pkuA_Q>
User-Agent Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.1.0
In-Reply-To <e0a56db4-6444-5dde-3fdc-e3237e669cc6@archlinux.org>
Content-Language en-US
Received-SPF pass client-ip=66.111.4.29; envelope-from=kfm@plushkava.net; helo=out5-smtp.messagingengine.com
X-detected-operating-system by eggs.gnu.org: First seen = 2020/08/06 09:15:43
X-ACL-Warn Detected OS = Linux 2.2.x-3.x [generic] [fuzzy]
X-Spam_score_int -20
X-Spam_score -2.1
X-Spam_bar --
X-Spam_report (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FROM_BLANK_NAME=0.723, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 <8a54cb1e-af78-f79f-6d73-6a235d707207@plushkava.net>
X-Mailman-Original-References <20200420051508.GA2359844@zx2c4.com> <7496b183-2db3-6c03-6074-928adcd08f45@case.edu> <CAHmME9pzOY_0EJ69y9wt6r-Jh3frZpV8XdFC6zG5EOkZ99h-1A@mail.gmail.com> <e0a56db4-6444-5dde-3fdc-e3237e669cc6@archlinux.org>
Xref csiph.com gnu.bash.bug:16711

Show key headers only | View raw


On 06/08/2020 13:33, Eli Schwartz wrote:
> On 8/6/20 6:05 AM, Jason A. Donenfeld wrote:
>> Hi,
>>
>> It may be a surprise to some that this code here winds up printing
>> "done", always:
>>
>> $ cat a.bash
>> set -e -o pipefail
>> while read -r line; do
>>         echo "$line"
>> done < <(echo 1; sleep 1; echo 2; sleep 1; false; exit 1)
>> sleep 1
>> echo done
>>
>> $ bash a.bash
>> 1
>> 2
>> done
>>
>> The reason for this is that process substitution right now does not
>> propagate errors.
> 
> Well, yes, it is an async command. But errexit has lots of other amusing
> traps, like
> 
> $ echo $(false)
> 
>> It's sort of possible to almost make this better
>> with `|| kill $$` or some variant, and trap handlers, but that's very
>> clunky and fraught with its own problems.
>>
>> Therefore, I propose a `set -o substfail` option for the upcoming bash
>> 5.1, which would cause process substitution to propagate its errors
>> upwards, even if done asynchronously.
> 
> Propagate the return value of async processes like this:
> 
> wait $! || die "async command failed with return status $?"

You beat me to it. I was just about to suggest wait $! || exit. Indeed, 
I mentioned the same in a recent bug report against wireguard-tools.

> 
>> It'd certainly make a lot of my scripts more reliable.
> 
> The use of errexit is the focus of a long-running holy war. Detractors
> would point out a very lengthy list of reasons why it's conceptually
> broken by design. Some of those reasons are documented here (including
> process substitution): http://mywiki.wooledge.org/BashFAQ/105
> 
> I recommend you do NOT claim this feature is a magic panacea that will
> make your scripts reliable; instead, just say you would find it useful.
>

I concur. The scripts I looked at tended heavily towards error handling 
at a distance and were already subject to one or two amusing errexit 
pitfalls.

-- 
Kerin Millar

Back to gnu.bash.bug | Previous | Next | Find similar


Thread

Re: process substitution error handling "" <kfm@plushkava.net> - 2020-08-06 14:15 +0100

csiph-web