Re: Execution of a data string

[Chet Ramey]

On 9/21/16 11:15 PM, mobatuorg@yahoo.ca wrote:

> Bash Version: 4.3
> Patch Level: 30
> Release Status: release
> _______________________________________________________________
> You can see in the picture below that:
>         declare -a "$ExecuteThisData"
> resulted in executing the string "$ExecuteThisData" without
> eval being explicitly invoked.  I believe this is unintentional since this
> is a variable assignment:

Not exactly, but the story is somewhat complicated.

`declare' is a builtin command.  It's not part of the shell syntax, so
its arguments undergo a round of word expansion before declare sees them.
It's also desirable to make something like `declare -a x=(foo bar)' work
the same as `declare -a x; x=(foo bar)', but that's problematic given
its status as a builtin instead of a reserved word.

The basic issue is that by the time declare sees it, there's very little
difference between

declare -a "$ExecuteThisData"
and
declare -a a=($Data)

As the shell has evolved, I've changed `declare' to behave more like a
reserved word than a regular builtin, so the arguments that look like
assignment statements before word expansion can be identified and
expanded like standalone assignment statements.  For backwards
compatibility, though, I retained the ability for declare to parse
compound assignment statements that aren't marked as assignment statements
by the parser.

There was an extensive discussion about this after bash-4.3 was released,
beginning at

http://lists.gnu.org/archive/html/bug-bash/2014-12/msg00028.html

that resulted in several changes to this type of construct in bash-4.4.
However, for backwards compatibility, constructs such as the one you
use are still accepted as they were in bash-4.2 and bash-4.3.

Chet

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet@case.edu    http://cnswww.cns.cwru.edu/~chet/