Re: local -r issue in conjunction with trap

[Koichi Murase]

2022年7月18日(月) 6:40 Chet Ramey <chet.ramey@case.edu>:
> On 7/15/22 7:06 PM, Koichi Murase wrote:
> > We can shadow local readonly variables. What we cannot are global
> > readonly variables.
> >
> > It seems to me a bug.
>
> It's not a bug. Bash-2.04 introduced behavior to disallow local variables
> with the same name as readonly variables in a previous scope (whether a
> local scope or not). I got requests to relax it, and the result is the
> current behavior of restricting it to shadowing readonly variables at the
> global scope.

Thank you for your explanation, but "it" (i.e., what seemed a bug to
me) is not the above behavior (allowing to shadow local readonly
variables), but the behavior that was initially reported in this
thread and that I described after that sentence in the same paragraph
(i.e., the behavior that shadowing local readonly variables fails with
particular conditions). Let me quote the paragraph again:

2022年7月16日(土) 8:06 Koichi Murase <myoga.murase@gmail.com>:
> It seems to me a bug. While the following works,
> $ bash-dev -ec 'T(){ local -r v=; }; trap T 0; F() { local -r v=; exit; }; F'
> the following fails
> $ bash-dev -e <<< 'T(){ local -r v=; }; trap T 0; F() { local -r v=; exit; }; 
> F'
> main: line 1: local: v: readonly variable

I expect the above small code works without the readonly-variable
errors because there are no global readonly variables. In fact, in
most cases, it works. However, only when the following three
conditions are met, the error message is output and the shadowing of
local readonly variables fails:

1) "set -e" is set.
2) The code is executed from a script file.
3) Shadowing of local readonly variables is attempted in a trap handler.

--
Koichi