Hi Chet, did you fix this? On Fri, Sep 25, 2026 at 11:46:47AM -0400, Chet Ramey wrote: > On 9/23/26 6:29 PM, Zev Weiss wrote: > > Hello, > > > > I've just noticed that the combination of 'set -e' and 'shopt -s > > execfail' produces (to me) surprising behavior. > > Thanks for the report. > > > Each on its own works as expected: > > > > $ bash -c 'set -e; /bin/enoent; echo foo' > > bash: line 1: /bin/enoent: No such file or directory > > $ bash -c 'set -e; /bin/enoent || echo foo' > > bash: line 1: /bin/enoent: No such file or directory > > foo > > $ bash -c 'shopt -s execfail; exec /bin/enoent || echo foo' > > bash: line 1: /bin/enoent: No such file or directory > > foo > > > > But when combined, an exec failure exits immediately even when it's the > > left operand of '||' (or an 'if' condition): > > > > $ bash -c 'set -e; shopt -s execfail; exec /bin/enoent || echo foo' > > bash: line 1: /bin/enoent: No such file or directory > > Yes. It's been this way forever (well, at least in bash terms). The issue > is that a low-level error function knows too much about whether or not > `errexit' is set. The fix is easy, but I'll have to trace through some > other code paths to make sure the change doesn't have side effects. I > don't think it will, but I have to check. > > > Is this a bug, or expected behavior for some subtle reason? (If the > > latter I think it might be helpful to clarify somewhere in the bash man > > page.) > > I think it's a bug in the case that `execfail' is enabled. Even in posix > mode -- `execfail' should override the usual POSIX requirement that a > non-interactive shell exit immediately if `exec' fails for any reason. > > Chet > I get foo being echoed at or near the devel tip:-
| 11:39:28$ echo $BASH_VERSION | 5.4.0(1)-devel[7cfdb340] | 11:40:23$ bash -c 'set -e; shopt -s execfail; exec /bin/enoent || echo foo' | bash: line 1: /bin/enoent: No such file or directory | foo | 11:40:26$ Cheers ... Duncan.
