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


Groups > gnu.bash.bug > #16714

Re: process substitution error handling

Path csiph.com!goblin2!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 15:26:14 +0100
Lines 32
Approved bug-bash@gnu.org
Message-ID <mailman.1012.1596723981.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> <b8fb1f5b-f8e4-b618-9c4e-7ccfa525f1f8@archlinux.org> <198e939d-5220-b23c-6c99-b2858bc94420@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 1596723981 2375 209.51.188.17 (6 Aug 2020 14:26:21 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=s EQEjlGwSoXQrwbPMeWtUJFSXwJQ3fHbJlLnRn+F6tM=; b=DLk+4bfMNHIs1R8Bb RF0Nlpb28iakbXOXWTuM8yiiiQxGv1KzYXBUAp4V40E7+sFyjWRYGGfxoUxrqLFD XJNGI8DZzONqaK6xNmWWtfLx/2QvJIY23pg5cy3BLkq6yL7eekgrJ8tQ6cppio0Z vRsCZ0PctIBlZqFglpffKAGYruLe1LAxONyLMPW16su1mEcjXd6Tkew6qDtg4CzA 2qvouppyVrPZ4w1PIePq4PlywuP8eoUMQKlUhY1OymyzONIfEQTA2gOiSwR5m0z8 ypM16KsSkAotinc2ie1ERVlSH9sYJskJjetF1iZcStOC8+QDl6LZyvYFgSOpS428 jOO6Q==
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=sEQEjlGwSoXQrwbPMeWtUJFSXwJQ3fHbJlLnRn+F6 tM=; b=GHkte4UmR+fHIt2JbJo1dUBG2bBp0Edu1UGXBnYsoxAhHFN1o0kXO8pL/ gz4QdlVCO6FJrVUTVpT9r7geAUdR8h6Fz3tuMhG5BgvRBtbMqpQdZG+hGLi02UUK q+H7S11z2s57qI1/hH4IcSscm68HaGOql97yaQvld4ieg8ZcrM/yR/uM0ZGt5G3Z n3DgVkDE5ycIJyw7UT/iSYKdCqC2fTJU9EyNeHYw4LKZTFYquG2UJLCTGvUdfr3R VP/VsRz27zXyfWs2SKuQCm8V42WJnBmAaU2CpvXkjyPDNXqHOr5cmaXM0IGaY+Ly MlMN2wA4gJda7ekxovLpPpD7+b/BQ==
X-ME-Sender <xms:CBMsX2pPSQX8r6OFb25qMPljtKU0P8SE_EYcjf8RNhxZvcQp50BAmw>
X-ME-Proxy-Cause gggruggvucftvghtrhhoucdtuddrgeduiedrkedtgdejkecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecuogfgmhhpthihtehlihgrshculddvtddmnecujfgurh epuffvfhfhkffffgggjggtgfesthejredttdefjeenucfhrhhomhepfddfuceokhhfmhes phhluhhshhhkrghvrgdrnhgvtheqnecuggftrfgrthhtvghrnhepvdejjefgleeuffetje effeejheehleeiieevveekvddvhfetjeehvddugfelgfdunecuffhomhgrihhnpehgihht hhhusgdrtghomhenucfkphepudelfedrudefkedrvddukedrudeltdenucevlhhushhtvg hrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehkfhhmsehplhhushhhkhgr vhgrrdhnvght
X-ME-Proxy <xmx:CBMsX0ooPofB87Ig--M6Fuk6696GUoVaTTLFWmQm4T0EqoMiaAIq4Q> <xmx:CBMsX7P7QbU8yQ5tJ-7ssnOlJrRGy-SShTYGHgt7htdu_Gh6uy6dwQ> <xmx:CBMsX15pIv1-Db2snEPiGt4LeDweLJGks_twCsppb01Ch77GeNIhrQ> <xmx:CBMsXwKMt23fk3mk-hqqOEtfHF0yK2n0IjKZfxFxf_5qhVxhW1j-1A>
User-Agent Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.1.0
In-Reply-To <b8fb1f5b-f8e4-b618-9c4e-7ccfa525f1f8@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 <198e939d-5220-b23c-6c99-b2858bc94420@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> <8a54cb1e-af78-f79f-6d73-6a235d707207@plushkava.net> <b8fb1f5b-f8e4-b618-9c4e-7ccfa525f1f8@archlinux.org>
Xref csiph.com gnu.bash.bug:16714

Show key headers only | View raw


On 06/08/2020 14:57, Eli Schwartz wrote:
> On 8/6/20 9:15 AM, kfm@plushkava.net wrote:
>> 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.
> 
> So if I understand correctly, you reported the lack of wait $! || exit
> in a script, and the script author instead responded by requesting a new
> feature in bash that does the same thing, except after a random interval
> during another command's execution?

Well, I wouldn't presume to know whether there is any relationship 
between said report and the feature request under discussion. Briefly, 
the errexit pitfall that affected me can be seen here:

https://github.com/WireGuard/wireguard-tools/blob/v1.0.20200513/src/wg-quick/darwin.bash#L299

I happened to mention that the exit status value of networksetup(8) is 
never checked and that it ought to be, with wait $! being one way of 
doing so. That being said, the proposed solution eschewed the use of 
process substitution altogether.

> 
>> 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.
> 
> lol, I bet we could fix that by adding even more error handling at a
> distance.
> 
-- 
Kerin Millar

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


Thread

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

csiph-web