Re: declare a="$b" if $a previously set as array

[Eduardo A . Bustamante López]

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!