On Mon, Dec 15, 2014 at 5:05 AM, Chet Ramey <chet.ra...@case.edu> wrote: > On 12/9/14 5:51 PM, konsolebox wrote: >> On Tue, Dec 9, 2014 at 7:29 AM, Linda Walsh <b...@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