On Mon, Dec 08, 2014 at 12:48:05PM -0800, Linda Walsh wrote: > --- This usage ***depends*** on delayed evaluation -- which you > claim is "code injection". This is the way shell is supposed to > operate. The programmer ***HAS*** to choose when to cause the expression > to be evaluated depending on their need. If you want delayed evaluation, use 'eval', that's what it's for. Your use case is a lame excuse for a "feature" that's clearly more evil than useful.
Also, it's *not* the way it's supposed to operate. Arrays are not POSIX, how can this be the way it's "supposed" to operate? Where do you get that from? | dualbus@hp ~/t % ls | bar foo | dualbus@hp ~/t % for shell in bash ksh93 mksh pdksh; do "$shell" -c 'typeset -a a b; x="(\$(ls))"; typeset a="$x"; b="$x"; typeset -p a b'|sed "s|^|$shell: |"; done | bash: declare -a a='([0]="bar" [1]="foo")' | bash: declare -a b='([0]="(\$(ls))")' | ksh93: a='($(ls))' | ksh93: typeset -a b='($(ls))' | mksh: typeset a='($(ls))' | mksh: typeset b='($(ls))' | pdksh: typeset a='($(ls))' | pdksh: typeset b='($(ls))' Bash is *evidently* the only shell in the family that does that "delayed evaluation" (i.e. *evaluates code when it SHOULD NOT*). Also, why is: declare foo="$bar" different from foo="$bar" The difference in ksh93 makes a little sense, you're resetting the variable's attributes with typeset, or defining a new variable. Introducing code evaluation, nope, doesn't make sense. The point of this kind of discussion is precisely to: - Hey, this feature is dangerous and kind of pointless - We should remove it, or at least disable it by default Not: - Hey, this feature is dangerous and kind of pointless - Sorry, that's how the shell is, live with it!