>then no more continued code man bash(1) says the following for the execfail option: execfail If set, a non-interactive shell will not exit if it can‐ not execute the file specified as an argument to the exec builtin command. An interactive shell does not exit if exec fails.
It says nothing about the traps getting reset. In my example the script clearly continues to execute after the failed exec, as it should (since execfail is set). -Mark On Thursday, September 30, 2021, 04:47:13 PM PDT, Alex fxmbsw7 Ratchev <fxmb...@gmail.com> wrote: i think its not a bug but normal runtime as ive understood, exec 'replaces' itself with <binary path arg>, then no more continued code well error checking could maybe be better On Fri, Oct 1, 2021, 01:25 Mark March <ma...@systempad.org> wrote: > If execfail is set, a failed exec does not cause a non-interactive shell to > exit, but it seems to reset the EXIT trap: > > cat <<'EOF' | bash > shopt -s execfail > trap "echo exiting..." EXIT > exec ~/does-not-exist > echo "exec failed in bash-$BASH_VERSION" > exit 1 > EOF > > Output: > > bash: line 3: /home/march/does-not-exist: No such file or directory > exec failed in bash-5.0.17(1)-release > > The "exiting..." line is missing. If you comment out exec ~/does-not-exist, > "exiting..." will be printed as expected. > I get this under 5.1.8 as well, built with gcc 9.3 This is on Ubuntu 20 on > x86_64. > > -Mark > >
