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