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 -- Marcin Owsiany <[EMAIL PROTECTED]> 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
