Re: unset does not act as expected on namerefs

[Chet Ramey]

On 5/27/15 8:25 AM, Greg Wooledge wrote:

>  1) It doesn't cross scopes.  It's not like Tcl's upvar at all.  It
>     only refers to a variable in the same scope (which, following the
>     standard bash rules, means it'll recursively search upward until
>     it finds a matching variable by name).  

This isn't about namerefs; namerefs don't change bash's scoping rules.


>  2) It allows arbitrary code execution, just like eval:
> 
>     imadev:~$ f() { declare -n foo="$1"; echo "$foo"; }
>     imadev:~$ f 'x[i=0$(date >&2)]'
>     Wed May 27 08:07:35 EDT 2015

So, given the nameref assignment, these two things are equivalent:

echo "${x[i=0$(date >&2)]"
echo "$foo"

You might have a beef with the subscript in an array reference undergoing
the usual set of word expansions, but this isn't anything nameref-
specific.

> Here's another surprise, that I didn't know until now.  Given the above,
> if we follow it up with another declaration of foo, it "hides" the
> nameref.   But the nameref declaration is still there, lurking, waiting.
> 
>     imadev:~$ declare -A foo
>     imadev:~$ foo["jug"]="brown"
>     imadev:~$ declare -p foo somevariable
>     declare -A foo='([jug]="brown" )'
>     bash: declare: somevariable: not found
>     imadev:~$ unset foo
>     imadev:~$ declare -p foo somevariable
>     declare -n foo="somevariable"
>     bash: declare: somevariable: not found

Thanks, this is an actual problem.  The 'declare -A foo' doesn't look up
foo for assignment, it looks up foo as if it were being referenced as $foo.
I'll see what I need to do to fix it.

Chet
-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRU    chet@case.edu    http://cnswww.cns.cwru.edu/~chet/