On Sat, Jul 06, 2024 at 01:41:01PM +0200, Jens Schmidt wrote:
> Today I came across this one:
>
> [copy-on-select-2]$ echo $BASH_VERSION
> 5.2.15(1)-release
> [copy-on-select-2]$ foo() { trap 'echo foo' RETURN; /bin/echo bar; }
> [copy-on-select-2]$ foo
> bar
> foo
> [copy-on-select-2]$ baz=$( foo )
> [copy-on-select-2]$ echo "<$baz>"
> <bar>
>
> I guess that Bash execve's the "/bin/echo" since it runs in a command
> substitution and the trap does not get executed, hence.
>
> As a work-around, one can tweak function foo so that the last command
> is not an external one, like this:
>
> [copy-on-select-2]$ foo() { trap 'echo foo' RETURN; /bin/echo bar; return
> $?; }
> [copy-on-select-2]$ foo
> bar
> foo
> [copy-on-select-2]$ baz=$( foo )
> [copy-on-select-2]$ echo "<$baz>"
> <bar
> foo>
>
> Would this be a bug?
>
> Should I report it separately on bug-bash?
>
> Thanks!
>
This is also reproducible on 5.2.26 and the devel branch:
bash-5.3$ foo() { trap 'echo foo' RETURN; /bin/echo bar; }
bash-5.3$ baz=$( foo )
bash-5.3$ declare -p baz
declare -- baz="bar"
bash normally disables the exec optimisation if there are EXIT traps,
but apparently it does not do it if there are RETURN traps in a
function.
CC+=bug-bash@gnu.org since this is a bug report
o/
emanuele6
