bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: declare -g var should return a nonzero return code when it fails


From: Chet Ramey
Subject: Re: declare -g var should return a nonzero return code when it fails
Date: Tue, 05 Nov 2013 16:30:45 -0500
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.0

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    address@hidden    http://cnswww.cns.cwru.edu/~chet/



reply via email to

[Prev in Thread] Current Thread [Next in Thread]