Re: Issue declaring an array via a variable name

[Greg Wooledge]

On Mon, Aug 16, 2021 at 04:10:31PM +0200, Alex fxmbsw7 Ratchev wrote:
> i dunno but, i had many testings many times
> the stable wanted is to enclose the per arg definition in quotes, not like
> "var"="var"
> the right dash options is also useful

I don't understand this paragraph at all.

> test=( a b ) t=var
> declare -ga "$t=( ${test@Q} )"

I believe this is what you're trying to show us:

unicorn:~$ declare -ga "${t}=( ${test@Q} )"
unicorn:~$ declare -ga "${t}"=( ${test@Q} )
bash: syntax error near unexpected token `('

And likewise,

unicorn:~$ declare -ga "$t=( ${test@Q} )"
unicorn:~$ declare -ga "$t"=( ${test@Q} )
bash: syntax error near unexpected token `('

There is something subtle happening there, at the parsing level.  Chet's
explanation (quoted below) may suffice for some.

For my own purposes, "if it hurts, don't do that" is good enough.
But that's just me.

> the same style i found secure and data preserving such alike:
> "list=( $( ls -Ac --quoting-style=shell-escape ) )"

That has nothing to do with the issue that started this thread.  You've
got a plain old compound array assignment, with a command substitution
inside it.  The variable on the left hand side ("list") is a valid
shell identifier.  There are no surprises here.

> On Mon, Aug 16, 2021, 15:57 Chet Ramey <chet.ramey@case.edu> wrote:
> > It's a syntax error. There is an unquoted operator (`(') where the grammar
> > does not allow it.
> >
> > `declare' does allow compound array assignment statements as arguments, and
> > the parser accommodates this as long as two conditions hold: the parser can
> > detect that the first word of a simple command is `declare' and the
> > argument is a valid assignment statement. In this case, the second fails,
> > since `"${variable}"' is not a valid shell identifier. That renders the
> > argument not a valid assignment statement.