thanks Stephane, it is indeed a good habit to sanitize the varname
whichever method is utilized. From your explanation I admit the eval
solution would have been equally valid
regards

Pier Paolo Grassi
linkedin: https://www.linkedin.com/in/pier-paolo-grassi-19300217
founder: https://www.meetup.com/it-IT/Machine-Learning-TO


Il giorno gio 16 apr 2020 alle ore 18:30 Stephane Chazelas <
stephane@chazelas.org> ha scritto:

> 2020-04-16 01:42:29 +0200, Pier Paolo Grassi:
> > Il giorno gio 16 apr 2020 alle ore 01:13 Mikael Magnusson <
> mikachu@gmail.com>
> > ha scritto:
> [...]
> > > : ${(PA)varname::=$array}
> > > (leave out the A for scalar assignment, and use AA for assoc arrays).
> [...]
> > Thanks! I was afraid I had to resort to eval.
> [...]
>
> What's wrong with "eval"? Note that many of those alternatives
> to "eval" are just other evals in disguise or are as dangerous
> (but giving the wrong impression that they're not).
>
> : ${(PA)varname::=$array}
>
> is a command injection vulnerability if the content of $varname
> is not sanitized.
>
>
> $ varname='x[$(uname>&2)]'
> $ : ${(PA)varname::=$array}
> Linux
> zsh: bad math expression: empty string
>
> So is:
>
> eval $varname'=("$array[@]")'
>
> but at least it's more obvious that it is.
>
> In any case, I'd expect the contents of $varname to be known and
> trusted in this case, while that of $array could be anything.
>
> Note that that "$array[@]" (instead of $array) is needed to
> preserve empty elements.
>
> --
> Stephane
>