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.
