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

[konsolebox]

On Mon, Dec 15, 2014 at 5:05 AM, Chet Ramey <chet.ramey@case.edu> wrote:
> On 12/9/14 5:51 PM, konsolebox wrote:
>> On Tue, Dec 9, 2014 at 7:29 AM, Linda Walsh <bash@tlinx.org> wrote:
>>
>>>         Instead of dumbing down bash, why not lobby for bash to record
>>> which variables contain tainted input -- and throw an error they are eval'ed
>>> (based on an option setting, of course)?
>>
>> For compatibility's sake I think it's a good idea to have an option
>> (through shopt [and set / a command-line argument]) to make a strict
>> behavior of declare in which assignment of variables are strictly the
>> same as the way they are normally assigned without it.
>
> This is unnecessarily limiting.  There's no reason to completely disallow
> constructs like `declare -x $one=$two' or even `declare -l a=$value'.  The
> question is what to do about potentially dangerous -- from some
> perspectives -- uses of those constructs.  So far we've identified
> compound assignment as one of those uses; assignment to an associative
> array using a subscript containing a command substitution might be another.

I'm not sure how about the former but 'declare -l a=$value' or
`declare -i x='1 + 1'` is good to me.  My only real concern about those
constructs is that values assigned to variables should not be
re-interpreted to make it appear as if it's part of the raw construct
itself besides when explicitly required e.g. $value should remain as
$value when assigned to `a` (besides transformation of uppercase
characters to lowercase forms) and `'1 + 1'` should literally be
 assigned to `x` besides another transformation through evaluation of
the arithmetic expression.

Not only are those values can be allowed for transformation because they
are explicitly required but also because they are safe in the sense that
their form is not in the form of assignments like those of indexed
arrays and associative arrays.  They are also not synonymous to how eval
does it.  The best thing as well is that they can be re-evaluated after
with another common function that's not necessarily part of declare's
implementation that declare itself would be the one to manage the
transformations i.e. `declare` would only care about assigning the raw
value and let other functions handle the transformation of the
variable's value after it.

Any other variable that is not declared to have transformations should
have values assigned to them -as is-.  If it's a normal variable or an
array variable, assignments like `a='[1]=2'` or `a=$something` should
only give the variable the literal value of `[1]=2` and `$something`
with no transformation at all.  If `a` turns out to be an array variable
(may it be an indexed or an associative array variable), `[1]=2` or
value of `$something` should be assigned to index or key 0 instead
(a[0]) therefore making it synonymous to `a[0]='[1]=2'` and
`a[0]=$something`.  No other forms of interpretation should be allowed.

And naturally if you have both -i and -a or -A on declaration, values
assigned to each element can also be transformed with arithmetic
expression.

This form of implementation should be prioritized.  The former
(declare -x $one=$two) is optional for the sake of compatibility or
flexibility if needed.

If we would allow forms like `declare -x $one=$two`, we should make sure
that $two remains intact as a single value.  If $one does not represent
a valid variable name (a form with a key or index should be illegal),
declare should simply throw an error.  $one should not be subject to any
form of transformation whether word splitting, pathname expansion,
arithmetic evaluation, command substitution, etc.  Of course, so is $two.

Last thing is `declare -x "$a_complete_assignment"` should not be allowed;
even quoted assignments like `declare -x "$one=$two"` simply because
they are already a reinterpreted form i.e. they are already evaluated
with a pair of single or double-quotes before declare tries to evaluate
them and it is were declare's behavior becomes inconsistent and it is
were everything starts going wrong.  If we do allow it, how would we
apply the proper rules to the expanded form of "$any"? - knowing that
"$any" is already a terrible combination of raw constructs and values
were literal values meant to be literal values become subject to
misinterpretation as forms of assignment to an array.  And what if
`$a_complete_assignment` contain `x=$something`, would we expand
$something or not?  This just makes implementation of declare way more
complicated, difficult and unclear.

And yes, I do imply that declare should just act like a reserved word
instead because it's for the best.

Cheers,
konsolebox