On 9/21/16 11:15 PM, mobatu...@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 c...@case.edu http://cnswww.cns.cwru.edu/~chet/
