[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: errexit inconsistent behaviour with pipelines

From: Marcin Owsiany
Subject: Re: errexit inconsistent behaviour with pipelines
Date: Mon, 6 Oct 2008 19:42:00 +0100
User-agent: Mutt/1.5.15+20070412 (2007-04-11)

On Mon, Oct 06, 2008 at 09:22:30AM -0400, Chet Ramey wrote:
> Marcin Owsiany wrote:
> > I expected that if a simple pipeline failure causes the shell to exit, and 
> > a simple for loop failure causes it to exit, then a failure in their 
> > combination would also cause an exit. However it is not so.
> You've found a probable bug, but it's not where you think.  Each element
> of a pipeline is run in a separate execution environment and a separate
> process.  Even if the child process inherits the errexit flag, the fact
> that false returns failure should not affect the parent shell: a pipeline
> is not a simple command.  You can see this by adding another process to
> the pipeline:
> set -e
> true | false | echo final
> echo after
> In all cases, `final' and `after' are both displayed.

Yes, I am aware that only the exit status of the last process in the
pipeline is ever propagated to the parent shell (unless you set
pipefail, in which case your example above will only print "final" and
not "after"). By the way - is pipefail a new thing? I only noticed this
last week, and I'm using bash for almost a decade :-)

> This bug only occurs when errexit is enabled and the final element of a
> pipeline is a simple command that returns a non-zero exit status.

Well, if the final element in the pipeline is a simple command, all
works as is supposed to. When it's a-not-so-simple command, like a for
or while loop, then it does not terminate the parent.

> I will devise a fix for the next bash release.

Great, thanks!

Marcin Owsiany <address@hidden>              http://marcin.owsiany.pl/
GnuPG: 1024D/60F41216  FE67 DA2D 0ACA FC5E 3F75  D6F6 3A0D 8AA0 60F4 1216
"Every program in development at MIT expands until it can read mail."
                                                              -- Unknown

reply via email to

[Prev in Thread] Current Thread [Next in Thread]