I just finished reading that 2018 discussion and the current discussion.
Its hard for me to understand why this is an issue. kre's use case was
unset X
y=$X
He called it 'braindead' for it to do anything expect to assign
NULL/empty to Y but I think that is far from true. If he's thinking of
'unset X' as assigning a NULL value to X (distinct from ""), 'local X'
(with no initialize) seems to be a much clearer way to do that.
What are people trying to accomplish by unsetting a variable in a
function that did not first declare it? (besides upVar which
specifically exploits the long standing behavior).
--BobG
On 8/1/22 09:58, Chet Ramey wrote:
On 7/30/22 8:05 AM, Kerin Millar wrote:
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.
Sometimes it's useful to read the discussion that prompted the change.
https://lists.gnu.org/archive/html/bug-bash/2018-02/msg00065.html
In this case, the primary requirement was to enable scripts that wanted a
wholesale behavior change, while not breaking backwards compatibility by
making that option the default. Enabling these semantics on a
per-variable
basis wasn't part of the discussion (kre was, however, very vocal about
making localvar_unset the default).
