|
From: | Robert E. Griffith |
Subject: | Re: functions can fully unset local vars in other scopes |
Date: | Mon, 1 Aug 2022 15:38:59 -0400 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0 |
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=$XHe 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 existingcommand 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 bymaking that option the default. Enabling these semantics on a per-variablebasis wasn't part of the discussion (kre was, however, very vocal about making localvar_unset the default).
[Prev in Thread] | Current Thread | [Next in Thread] |