On Fri, Mar 7, 2014 at 1:38 PM, Eduardo A. Bustamante López
<dual...@gmail.com> wrote:
> WARNING: the codes given below cause the shell to enter an infinite
> loop.
>
>
> Both:
> dualbus@debian:~$ bash -Tc 'f(){ :; }; trap return RETURN; f'
> ^C
>
> and:
> dualbus@debian:~$ bash -c 'f(){ trap return RETURN; }; f'
> ^C
>
> Cause the function call to recurse infinitely. I would understand if
> this is labeled as a feature, rather than a bug (in the sense that
> the user shouldn't be putting return inside a return trap :), so one
> can safely assume that if they did it, it's because they wanted the
> infinite recursion).
>
> Though, I think the following 2 approaches would be better/more
> consistent.
>
> (1) treat the execution of return inside a RETURN trap as an error,
> like when 'return' is called outside a function/sourced script.
>
> (2) treat return specially when it's executed inside a return trap,
> making it return immediately from the trap.
>I know we've discussed this off-list, but I'll restate that I've known about this for a long time and never considered it a bug. The return status currently remains that of the last command or return evaluated prior to the trap, which is consistent with my reading of the spec. The recursion is not necessarily infinite. The return call may be guarded by some condition, or the trap may be unset within the trap prior to calling return. Consider also that unless another return trap is already set on the direct caller, setting the RETURN trap sets the trap on every caller out to the next scope in which a different RETURN trap was set. What will happen now when return is called from such a trap? Will it fire the next-outermost trap or simply return ignoring the trap for just the current scope? I actually have code that depends upon the way RETURN trap nesting works now (not really on this behavior of calling return though).
