In rawhide rpmbuild does not fail (abort the build) when a patch does not apply. I consider this change as a bug because this way maintainers might not notice that a patch needs rebasing and ship a broken package. In my case I upgraded beagle to 0.3.9 in rawhide (a patch did not apply), I only noticed that when backporting the release to F10 where rpm behaves as expected. (i.e patch does not apply -> build fails). Please revert this change, before it causes more confusion and surprises.
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.