Date: Thu, 11 Jul 2024 16:01:20 -0400
From: Chet Ramey <chet.ra...@case.edu>
Message-ID: <2739cbbc-d44e-423e-869e-f2884c148...@case.edu>
| The bug in bash-4.2 was that [...]
| This would have been clearer to see (and more misleading) if the variable
| x also had a value at the global scope.
If anything, I'd say that the fix does not go far enough. There is
no conceptual difference (in sh) between any type of unset variables,
whatever other attributes they might have. All the conceivable variables
that could ever exist are essentially just unset, with no assigned
attributes (unless the -a option is enabled, in which case all those
unset, unknown, variables have the export attribute), until they are
perhaps given one - they remain unset until given a value.
To the implementation they're different, there's no way for the
implementation to remember every possible variable name, with its
non-value and no attributes, nor is there any point, such a thing
can be created whenever it is required to exist, and then destroyed
again later - but that's just an implementation technique, another
would be for variables once created to be retained forever, even if
unset and with no attributes.
But there's no reason to expose any of this to the application, all
unset variables should behave identically - whether they have attributes
or not (except in how the attribute affects them when a value is assigned).
So, I'd say that the current bug is, from the original report here:
wer...@suse.de said:
| ... for global variables it works as expected.
That should be fixed, and "declare -p var_name_never_seen_before"
should output either
declare -- var_name_never_seen_before
or perhaps, if it has no attributes
unset -v var_name_never_seen_before
If that result is later eval'd, perhaps in a different shell instance,
where that name has also never previously been noted, then whether or
not the shell creates a variable struct for it, or not, is irrelevant
to anything (except implementation convenience) and the behaviour
should be identical.
That is, other than syntactically incorrect variable names, declare -p
should never generate an error.
Further, if "localness" is considered an attribute of a variable (which
isn't how I would implement it, but assuming it is) then surely declare
should have an option to set the local attribute, and declare -p should
generate a command which restores that (just as it does for the export
attribute, the integer attribute, and I assume, others.
kre
