On 12/8/14 4:56 AM, Stephane Chazelas wrote:
> I'm saying that if a script writer writes:
>
> declare a="$b"
>
> intending to declare the *scalar* varible "$a" as a copy of the
> scalar variable "$b" (and remember that in ksh/bash, scalar
> variables and arrays are not very differentiated, $a being
> ${a[0]}), and overlooked (or is not aware of (because that was
> done by 3rd party code for instance)) the fact that the variable
> was used as an array before (for instance because he used
> a[0]=foo instead of a=foo for instance), then:
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.
> - 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.
Well, I don't think it's particularly a syntax issue. It's the question
I wrote in my previous message: how much further should we move compound
assignment away from the execution semantics associated with builtins.
> - and it's not consistent when the same assignment is done
> without "declare" (and no, I don't agree "declare" is a mere
> builtin as it's already parsed halfway between a builtin and an
> assignment).
I understand what you're saying. It's true that bash treats arguments
to declaration commands differently from arguments to other builtins.
The question is twofold: the appropriate semantics and the amount of
backwards compatibility to sacrifice.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRU c...@case.edu http://cnswww.cns.cwru.edu/~chet/
