Date: Fri, 23 Feb 2024 10:45:01 -0500
From: Chet Ramey <chet.ra...@case.edu>
Message-ID: <3544bf1c-e8f6-4358-a281-24bd1be7d...@case.edu>
| Do you mean that unset can mark local variables at the same
| scope as unset,
no, but see below.
| that unset can remove local variables at a previous scope,
yes, that one, but again, see below. But note, had you said
'unset' there instead of 'remove', it would all be fine.
| or that unset in a shell function can unset global variables?
no, of course not.
But I think the real issue here is that we would use the term 'scope'
with respect to shell variables at all, it really isn't appropriate.
The non-standard command 'local' which we all have, in slightly
different forms, but with similar enough effect that most simple
usages work fine in all shells, would better be called 'save'
(or something similar) as its real purpose is to preserve the
current state of a variable so that can be restored when the
functuon exits. Once that's done, everything else (unset included)
just operates in the global var as if the 'local' (or 'save')
never happened.
This turns out to be quite similar to dynamic scoping, with
some subtle differences, but fits the shell's model of variable
use (everything is global, there is exactly one var named PATH
or IFS (etc)) better than actual dynamic scoping.
kre
ps: it is immaterial here what other effects the local command
has on the variable, once the previous val/state has been saved,
also having it unset the var, or assign it '', or alter
attributes (remove export for example) is unimportant. Clearly
what, if anything, happens makes (or might) a difference to
the script, but none of that kind of variation affects the model.
