[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: process substitution error handling
From: |
Oğuz |
Subject: |
Re: process substitution error handling |
Date: |
Thu, 6 Aug 2020 16:02:19 +0300 |
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
Re: process substitution error handling, Chet Ramey, 2020/08/06