Re: [bash 4.2] `declare -g' bug?

[Greg Wooledge]

On Fri, Feb 18, 2011 at 11:25:48AM +0800, Clark J. Wang wrote:
> A global var can always be declared out of a func (usually at the beginning
> of the script) so what's the main intention of introducing a new `-g'
> option?

The main reason, as I understand it, is so that you can declare an
associative array inside a function and have it be readable in the
caller.  Unlike all other variables (strings, regular arrays), associative
arrays *must* be declared.  But the declare builtin had the unfortunate
(for some purposes) side effect of also marking the variable as local.

Prior to bash 4.2, any such associative array would have to be declared
outside the function.  So, imagine a function like:

# pqp - parse query parameters
# Input: QUERY_STRING environment variable
# Output: associative array 'qparams' containing CGI parameters as keys.
# (If a parameter is repeated, only the last instance is retained.)

In bash < 4.2, the caller would have to pre-define the qparams associative
array, because the function cannot declare it at the global scope.
In bash 4.2, the function can create the array itself.  Is that a huge
difference?  Maybe not, but it's just more natural to do it the 4.2 way.

> And If we can declare/modify a global var in a func but we cannot read it
> from in the func I don't think the feature is very useful to people.

Your example was interesting, but it was extremely convoluted.  I tell
people over and over that writing big complicated shell scripts (or
worse, "reusable libraries" of shell code... *shudder*) is simply a
BAD idea.  But nobody ever listens.

In the normal case, when you write a shell script that only has one or
two functions in it, and there's no shadowing of global variables with
local variables by the same name, everything works as you expect.  I'll
let you and Chet hammer out what to do in the more complex cases.