bug-bash
[Top][All Lists]
Advanced

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

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


From: Clark J. Wang
Subject: Re: [bash 4.2] `declare -g' bug?
Date: Fri, 18 Feb 2011 22:23:57 +0800

On Fri, Feb 18, 2011 at 9:35 PM, Greg Wooledge <wooledg@eeg.ccf.org> wrote:

> 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.
>
>
Thanks for the kind explanation, Greg.

I think the problem is that if people do not understand the feature
requirement so they just cannot understand the feature well unless the
feature works in a straightforward way. That's why I asked the question.


> > 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.
>
>
Agree. I was offen depressed because of that. :)


> 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.
>



-- 
Clark J. Wang


reply via email to

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