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

[Linda Walsh]

Chet Ramey wrote:
> On 12/8/14 4:56 AM, Stephane Chazelas wrote:
>
> > I'm saying that if a script writer writes:
> >
> >     declare a="$b"
>
> I don't think it's unreasonable for a script writer to expect that
> this does not unset a; it's not documented to do that, and assignment
> without the `declare' doesn't unset it.  Assignment without declare
> also pays attention to the variable's state: assigning to `a' as if it
> were a scalar doesn't magically convert it from an array to a scalar;
> it assigns element 0, as you know.
====
        Similarly, if you use 'set', or 'shopt', they doesn't reset
all the state variables addressable w/those commands.  declare can
be used to toggle those variable attributes w/o destroying the rest.

Though I just ran into a bit of weirdness (in 4.2.45)
(output is commented out and indented):

env -i /bin/bash --norc --noprofile
declare -a ar=(ONE TWO THREE)
declare -p ar
#       declare -a ar='([0]="ONE" [1]="TWO" [2]="THREE")'

#### add 'l', and note output:

declare -al ar=(${ar[@]})
declare -p ar
#       declare -al ar='([0]="ONE" [1]="TWO" [2]="THREE")'   # Note - no 
conversion

# ok, now set export:
declare -x ar=(${ar[@]})
declare -p ar
        declare -axl ar='([0]="one" [1]="two" [2]="three")' # now "-l" 
takes effect

---
Same thing happened w/integers... delayed conversion.

Weird. prolly fixed. (?)

> > - it will work in most of the cases (and that's one aspect why
> > it's dangerous, because it's hard to detect).
> > - but you've got a code injection vulnerability (in the very
> > special case where $b starts with "(".
> > - for no good reason. See ksh for a better syntax that doesn't
> > have the issue.
----
It is code injection because the script writer is using unchecked
input.

That's why I thought it might be a "way out" to "evolve" bash to
know what vars come from the user or the environment -- then
shopt -o no_eval_tainted

would throw an error on *any* eval (whether it uses 'eval' or
not).  (obviously not happening overnight, but it would be
more than a simple band-aid correcting this one use case

It's still a script writer's responsibility to check input
before blindly using it: this isn't considered a bug in
the C language -- but it is considered unsafe practice:

     char * buff = getenv("PATH");
     printf(buff);

Do you really think BASH should be changed because of
bad practice?