On 11/4/13 4:24 AM, Peggy Russell wrote:
>>> "declare -g var" should return a nonzero return code when it fails.
>
>> There is a problem here, and the problem that causes the spurious error
>> message from test_error has been fixed in bash-4.3. However, I don't think
>> you completely understand what bash scoping is, or what makes a variable
>> set or unset.
>
> Is the problem that is fixed in 4.3, that "declare -p" returns "bash:
> declare: var: not found" for variables that are unset?
No. The problem is that there is a bug in the declare -g code that makes
subsequent lookups report a variable not found error instead of finding
the local instance of `var' with value `data2'. I didn't look too far to
see exactly what it was, since it's fixed in bash-4.3.
>> First, using declare without assigning a value creates a variable
>> "placeholder". The variable exists as more-or-less invisible, but is not
>> considered set until it is assigned a value. Therefore, declare -g var
>> just creates a placeholder at the global scope if there is no existing
>> global variable with that name. If there is such a variable, it's a
>> no-op. The `redeclare local variable as global' comment is just > incorrect.
>
> Poor choice of words. Just experimenting here to understand the bounds. A
> local variable is "unset", and a new globally scoped variable with the same
> name is created. But a globally scoped variable is not created...
Sort of. A local variable is created and given a value (`data2'). That
changes its state to set. It's true that a `placeholder' global variable
is created when you run `declare -g var', but since it has not been given
a value it is unset.
The easiest thing to remember is that a variable is not set until it's
been given a value, even if it has been given attributes using `declare'.
> The "placeholder" is still there for the locally scoped variable, isn't it,
> and this goes back to the beginning of this thread and the fix for 4.3...
> "declare -p" gives the impression that bash knows nothing about the locally
> scoped variable.
Correct, that's the bug. The local variable still exists and is set, and
bash should find it when you run `declare -p'.
> This makes a lot more sense. As far as return codes go it is 0 because it
> isn't failing at all. Declaring a global variable that already exists as a
> globally scoped variable is a no-op, and in a function declaring a global
> variable that already exists as a locally scoped variable, bash uses the
> locally scoped variable.
Yes.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRU c...@case.edu http://cnswww.cns.cwru.edu/~chet/
