Declare command and shell expansion

Question

I stumbled by accident on the following bash behaviour, which is for me kind of unexpected.

# The following works
$ declare bar=Hello                               # Line 1
$ declare -p bar                                  # Line 2
declare -- bar="Hello"
$ foo=bar                                         # Line 3
$ declare ${foo}=Bye                              # Line 4
$ declare -p bar                                  # Line 5
declare -- bar="Bye"
# The following fails, though
$ declare -a array=( A B C )                      # Line 6
$ declare -p array                                # Line 7
declare -a array=([0]="A" [1]="B" [2]="C")
$ foo=array                                       # Line 8
$ declare -a ${foo}=([0]="A" [1]="XXX" [2]="C")   # Line 9
bash: syntax error near unexpected token `('`
# Quoting the assignment fixes the problem
$ declare -a "${foo}=(A YYY C)"                   # Line 10
$ declare -p array                                # Line 11
declare -a array=([0]="A" [1]="YYY" [2]="C")

Since shell expansion

1. Brace expansion
2. • Tilde expansion
   • Parameter and variable expansion
   • Arithmetic expansion
   • Process substitution
   • Command substitution
3. Word splitting
4. Filename expansion

is performed on the command line after it has been split into tokens (followed by quote removal) but before the final command is executed, I would not have expected line 9 to fail.

Which is the rationale behind it, that makes bash not accept line 9? Or, said differently, what am I missing in the way line 9 is processed by bash that makes it fail but makes line 10 succeed?

In any case, quoting is not always going to straightforwardly work and it would require extra attention in case the array elements are strings with e.g. spaces.

Answer 1

tl;dr; I think it's just a syntax quirk, and you shouldn't presume some grand design behind it.

Bash is using a bison/yacc-generated parser, but just like with many other languages (C, perl, etc), it's not a "clean" parser, but it's also keeping some state separate/parallel to the grammar in the parser_state variable.

A flag kept in that state variable is PST_ASSIGNOK. That will be set when some builtin which was parsed as a WORD token had ASSIGNMENT_BUILTIN in its flags.

Such "assignment builtins" are local, typeset, declare, alias, export and readonly.

The PST_ASSIGNOK will direct the parser to consider parentheses as part of a WORD token when used after an assignment at the right of such a builtin. But it will NOT change the rules which determine whether the current token is actually an assignment: Since ${foo}=(...) is not an acceptable assignment, it will not be parsed as a single word, and the parentheses will trigger a syntax error just like in echo foo(bar).

After a command line was parsed, it will be expanded, and as part of the expansions, any compound assignment (WORD which was marked with W_COMPASSIGN) like var=(1 2) will be performed and replaced with var, which will then be passed as an argument to a builtin like declare. But if declare, after all the expansions, gets an argument of the form var=(...), it will parse and expand it itself again.

So, varname=foo; declare "$var=(1 2 3)" may be similar to declare foo='(1 2 3)'. Or to declare foo=(1 2 3), depending on whether the variable was already defined:

$ declare 'foo=(1 2 3)'; typeset -p foo
declare -- foo="(1 2 3)"
$ declare foo=(1); typeset -p foo
declare -a foo=([0]="1")
$ declare 'foo=(1 2 3)'; typeset -p foo
declare -a foo=([0]="1" [1]="2" [2]="3")

I don't think it's a good idea to rely on this corner case:

$ declare 'bar=(1 ( )'; typeset -p bar
declare -- bar="(1 ( )"
$ declare bar=(1); typeset -p bar
declare -a bar=([0]="1")
$ declare 'bar=(1 ( )'; typeset -p bar
bash: syntax error near unexpected token `('