[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: functions can fully unset local vars in other scopes
From: |
Kerin Millar |
Subject: |
Re: functions can fully unset local vars in other scopes |
Date: |
Sat, 30 Jul 2022 13:05:18 +0100 |
Hi Martin,
On Sat, 30 Jul 2022 11:47:01 +1000
Martin D Kealey <martin@kurahaupo.gen.nz> wrote:
> On Fri, 29 Jul 2022 at 18:51, Kerin Millar <kfm@plushkava.net> wrote:
>
> > 5.0 added a localvar_unset option that impedes the behaviour of 'popping'
> > from the outermost scope.
I would have preferred for the sentence to have been quoted in full.
> >
> > $ bash -c 'x=foo; f1() { local x=bar; f2; x=baz; }; f2() { unset x;
> > declare -p x; }; f1; declare -p x'
> > declare -- x="foo"
> > declare -- x="baz"
> >
> > $ bash -O localvar_unset -c 'x=foo; f1() { local x=bar; f2; x=baz; }; f2()
> > { unset x; declare -p x; }; f1; declare -p x'
> > declare -- x
> > declare -- x="foo"
> >
>
> Whilst I have serious misgivings about the old behaviour, I find this
> approach *deeply* unsettling, introducing yet more action at a distance:
> modifying the behaviour of *existing* code by changing a global option that
> didn't even exist when the code was written. Whilst it's possible to
> localize the effect of shopt so it doesn't leak out, that's an extra step,
> making it likely to be overlooked.
>
> I'll grant that this new shopt is significantly better than simply changing
> the default behaviour and then requiring compat44 to get the old behaviour
> back (*1), and that version control is "hard", but adding yet another
> global setting seems to be going in entirely the wrong direction.
I'm inclined to agree.
>
> I'm aware that there are historical choices that later turned out to be
> suboptimal, but it seems like the better way to fix them is not to
> unwittingly change the behaviour of existing code, but rather to introduce
> new commands or options to get the new behaviours (*2).
>
> What consideration was given to creating “local --unset *VAR*” or “unset
> --local *VAR*” or some other equivalent that doesn't overload any existing
> command form?
Obviously, only Chet can meaningfully respond to this. I mentioned the
existence of the option because it appeared likely that Emanuele was unaware of
it, not to attempt to obviate any of his suggestions, nor endorse the status
quo.
--
Kerin Millar