Re: currently doable? Indirect notation used w/a hash

[Dan Douglas]

On Friday, June 14, 2013 06:02:15 AM Dan Douglas wrote:
> On Monday, June 10, 2013 09:39:56 AM Greg Wooledge wrote:
> > > On 10 Jun 2013 14:15, "Chris F.A. Johnson" <chris@cfajohnson.com> wrote:
> > > >    It is not the least bit difficult with eval:
> > > >
> > > > eval "array=( \"\${$1[@]}\" )"
> > 
> > On Mon, Jun 10, 2013 at 09:17:23PM +0800, Chris Down wrote:
> > > Enjoy your arbitrary command execution.
> > 
> > To be fair, Chris Johnson was probably assuming a programming environment
> > where the function is only callable from within the same script, and
> > thus has only trustworthy arguments provided by the caller.  Sometimes,
> > this is the case.  Sometimes, it isn't.
> > 
> > In a more general sense, using eval SAFELY requires undergoing several
> > tedious steps.
> 
> You're aware of this. For the record, there should never be a situation where 
> a variable name isn't guaranteed. All builtins that accept variable names, 
> arithmetic variable dereferences, and indirect variable expansions are 
> exploitable, not just eval. It never makes sense to have the name of some 
> internal label not controlled entirely internally.
> 
> If it's a library function used by some other script, then responsibility for 
> making that guarantee is inherited by the library consumer. There's no 
> difference.
> 
> To validate a "parameter name" fully requires a full shell parser, because 
> the 
> subscript of an indexed array is effectively a part of its name as far as 
> Bash 
> is concerned.
> 

Also forgot to mention (though it should be obvious).

 $ ~/doc/programs/bash43 -c 'function f { typeset -n x=$1; : "$x"; }; a=(yo 
jo); f "a[\$(echo yes this even applies to namerefs>&2)0]"'
yes this even applies to namerefs

In a nutshell bash namerefs don't actually enable any new functionality. It's
just a convenient syntax, makes dealing with keys indirectly easier, and
improves portability in some limited cases.

-- 
Dan Douglas