maybe its scope ..
1st define trap 2 define and run func ..
On Sat, Jul 6, 2024, 15:02 Emanuele Torre <torreemanue...@gmail.com> wrote:
> 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
>
>
