Re: EXIT trap is not executed after an exec failure in a non-interactive shell

[Mark March]

>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 
<fxmbsw7@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 <march@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
> 
>