Re: [3.0.13] declare -a a=('$0')

[Chet Ramey]

> > > declare seems to evaluate its arguments:
> > 
> > It does.  The process is actually very regular.
> > 
> > Assignment statements (at least compound assignment statements)
> > appearing
> > as arguments to `assignment builtins' are parsed specially -- as a
> > single
> > word.  The word becomes one of the arguments to `declare', but marked as
> > an assignment.
> > 
> > Each argument to declare is expanded.  The words marked as assignments
> > (since `declare' is an `assignment builtin') are expanded exactly as
> > assignments preceding commands.
> 
> That's not clear to me.

You stopped in the middle.  This is what happens before declare is invoked.
Your example supports this.

> bash-3.00$ env -i /usr/local/bin/bash -c 'a=(1 \$PATH) env'
> a=(1 $PATH)
> PWD=/export/home/chazelas
> SHLVL=1
> _=/bin/env
> 
> (here, $PATH was not expanded). But that makes no sense to pass
> an array as an environment variable of a command.

True enough, though some versions of ksh try (though not using this format).
caleb.INS.CWRU.Edu(2)$ cat x15
zzz=(1 2)

export zzz
printenv zzz
caleb.INS.CWRU.Edu(2)$ ksh93 ./x15
1

> > When declare is run, it re-parses the arguments that appear to be
> > compound
> > assignments.  It does the expansion, because at this point there's no
> > way
> > to tell whether or not the original assignment was quoted.
> 
> I'd think that's why it shouldn't be *parsed* as a command (ksh,
> whose "type" lies when it pretends "typeset" is a "builtin"). Or
> that it should be parsed as any other command and therefore that
> array assignments are made impossible.
> 
> > declare has to do some reparsing, since it only gets a single argument
> > and
> > has to somehow split it and understand [index]=value.  It uses exactly
> > the
> > same code as compound assignments preceding commands.
> 
> What do you mean by "compound assignments preceding commands"?

It's posix-speak.  Assignment statements are referred to as preceding
commands, even if there are no `command words' (which are optional). 
In this case, compound assignments are not allowed preceding non-empty
commands.

> Still, that doesn't make much sense to have two different
> parsings for
> 
> array=(...)
> and
> declare -a array=(...)

Agreed, it should be cleaner than it is.  I'll have to see if there's
a clean way to avoid the double-expansion, but only for compound array
assignments.  And without breaking backward compatibility too badly. 

> (especially when it's not documented and not compatible between
> versions of bash).

You want bug-for-bug compatibility?  I should go home now.

> The simplest, to my mind is not to allow array assignment with
> "declare".

Simple, but not backwards-compatible.

Chet

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
( ``Discere est Dolere'' -- chet )
                                                Live...Laugh...Love
Chet Ramey, ITS, CWRU    chet@po.cwru.edu    http://tiswww.tis.cwru.edu/~chet/