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" <ch...@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
