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

Groups > gnu.bash.bug > #16710 > unrolled thread

Re: process substitution error handling

Back to article view | Back to gnu.bash.bug

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: process substitution error handling Oğuz <oguzismailuysal@gmail.com> - 2020-08-06 16:02 +0300

#16710 — Re: process substitution error handling

6 Ağustos 2020 Perşembe tarihinde Greg Wooledge <wooledg@eeg.ccf.org> yazdı:

> 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?
>
>
My thoughts exactly. That would be disastrous.


> 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.
>
>

-- 
Oğuz

[toc] | [standalone]

Back to top | Article view | gnu.bash.bug

csiph-web