On Tue, Mar 10, 2015 at 6:57 PM, konsolebox <konsole...@gmail.com> wrote:
> On Fri, Mar 6, 2015 at 7:14 AM, Chet Ramey <chet.ra...@case.edu> wrote:
>
>> At some point, I may take a look at changing this, but it would not be
>> backwards compatible, and that is undesirable. It doesn't help you
>> now, either.
>>
> That behavior probably would be better left untouched. We wouldn't want
> another
> inconsistent delayed evaluation confusion like what we had on declare. The
> behavior also would already be different from other shells.
>
> A possible problem could arise if unset tries to unset a set of words that
> come
> from an expanded array e.g. "${NAMES[@]}" in which the expanded version
> would also have expanded characters giving possibility to unset unexpected
> parameters. That would now be an added consideration. There would be
> other issues as well probably.
>
> unset should remain a simple builtin command that processes expanded
> arguments without going for another expansion.
Sorry about this. My reply was reckless and misinformed. unset
actually expands
the subscript. The proper way should have been to just allow
arithmetic expansion
on indexed arrays (without or not allowing any form of parameter expansion,
double-quote, single-quote, backslash or indirect (with $) parameter expansion;
if the subscript is not a clean form of arithmetic expression, it
should produce an
error message). As for associative arrays, no expansion should happen at all.
The subscript should be interpreted as is. It would only require that the end
character of the word argument should be ].
Looks like compatibility is really something that should be considered.
