On Mon, 11 Mar 2024 11:45:17 -0400
Chet Ramey <chet.ra...@case.edu> wrote:
> On 3/11/24 12:08 AM, Kerin Millar wrote:
>
> > Speaking of which, to do both of these things has some interesting effects
> > ...
> >
> > $ z() { local -g a; unset -v a; a=123; echo "innermost: $a"; }; unset -v a;
> > x; declare -p a
> > innermost: 123
> > inner: 123
> > outer: 123
> > declare -- a
> >
> > $ z() { local -g a; unset -v a; unset -v a; a=123; echo "innermost: $a"; };
> > unset -v a; x; declare -p a
> > innermost: 123
> > inner: 123
> > outer: 123
> > declare -- a="123"
>
> These show the normal effects of unset combined with dynamic scoping. This
> ability to unset local variables in previous function scopes has been the
> subject of, um, spirited discussion.
Of course, you are right. I had confused myself into thinking that there was
some curious interaction between -g and the scope peeling technique on display
there but I just tested again and could observe no adverse interaction. I'll
attribute that to only being half-awake at the time.
>
> > $ x() { local a; y; local +g a; a=456; echo "outer: $a"; }; unset -v a; x;
> > declare -p a
> > innermost: 123
> > inner: 123
> > outer: 456
> > declare -- a="123"
>
> Let's assume the previous function definitions remain in effect here. In
> that case, z continues to unset the local variable definitions in previous
> scopes, but the `local +g a' is basically a no-op -- it implies not using
> the global scope for a, which is the same as not using the option at all.
Thanks. To confirm this, I replaced "local +g a" with "local a" and saw that it
continued to have the same effect of preventing the assignment of 456 from
happening in the global scope. It came as a minor surprise but does make sense,
given the purpose of local.
--
Kerin Millar
