Bug 483385

Easily reproduced locally in mock rawhide root, dropping bash down to 3.2 from F10 restores normal behavior, ie error out.

This is not caused by rpm change, this is either an intentional change of behavior or bug in bash 4.0. CC'ing bash maintainer for comments.

Ok here's a minimal reproducer, surely this is not intentional:
---
#!/bin/sh
echo foo|cat /nosuchfile
echo "here: $?"
---

With bash 3.2.39 from F10:
[pmatilai@turre ~]$ sh -e /var/lib/mock/fedora-rawhide-x86_64/root/tmp/bashtst.sh 
cat: /nosuchfile: No such file or directory
[pmatilai@turre ~]$

With bash 4.0.0(1)-rc1 from rawhide:
mock-chroot> sh -e /tmp/bashtst.sh 
cat: /nosuchfile: No such file or directory
here: 1
mock-chroot>

It's the pipe that throws bash off somehow, despite getting error code right. Removing "echo foo|" makes bash 4 error out at the failing 'cat'.

Created attachment 330527 [details]
Revert to former behavior

From execute_cmd.c:

      /* 10/6/2008 -- added test for pipe_in and pipe_out because they indicate
         the presence of a pipeline, and (until Posix changes things), a
         pipeline failure should not cause the parent shell to exit on an
         unsuccessful return status, even in the presence of errexit.. */

Attached patch "fixes" this by removing the new pipe-checks, correct it probably is not :) I dunno what POSIX says about this but it's not the pipe itself that's failing here, the last command of the pipeline is.

Panu hits the nail on the...
If there will be check like (exit_immediately_on_error && pipe_in == NO_PIPE && pipe_out == NO_PIPE && exec_result != EXECUTION_SUCCESS), then bash -e will never exit immediately if a command (in this case pipeline) exits with a non-zero status.
Bug reported upstream: 
http://groups.google.com/group/gnu.bash.bug/browse_thread/thread/6a866bd374c1bf9d#

The Posix says:
-e
    When this option is on, if a simple command fails for any of the reasons
listed in Consequences of Shell Errors or returns an exit status value >0, and
is not part of the compound list following a while, until, or if keyword, and
is not a part of an AND or OR list, and is not a pipeline preceded by the !
reserved word, then the shell shall immediately exit.

For me this looks like that Posix is not clear as it should be. They are
talking about simple commands, but later the words `s not a pipeline preceded
by the ! reserved word' makes no sense, if they are talking only about simple
commands...

I have already brought this up with the Austin Group.

https://www.opengroup.org/sophocles/show_mail.tpl?CALLER=index.tpl&source=L&listname=austin-group-l&id=11862

One follow-up is

https://www.opengroup.org/sophocles/show_mail.tpl?CALLER=index.tpl&source=L&listname=austin-group-l&id=11863


I think the consensus is that the new bash behavior is wrong.  Chat used POSIX compliance as the argument to change it.  This will hopefully mean he'll change it back before 4.0 final.

For the RH bash 4.0.rc1 package, the maintainer can and should already release a new version of the RPM with this change reversed.

Fixed in bash-4.0-0.4.rc1.fc11

*** Bug 485584 has been marked as a duplicate of this bug. ***

No other problems -> closing.