On 12/8/14 9:51 PM, konsolebox wrote:
> On Sun, Dec 7, 2014 at 7:24 AM, Stephane Chazelas
> <stephane.chaze...@gmail.com> wrote:
>> $ b='($(uname>&2))' bash -c 'a=(); declare -r a=$b'
>> Linux
>
> I actually also don't like that form of implementation. Even if declare
> is a builtin and not a reserved word, it still has some special
> treatments that's different from a simple command. For example in a
> simple command like echo, something like 'echo a=(1 2 3 4)' would cause
> syntax error. Word splitting and pathname expansion also doesn't happen
> unless when assigning elements in an array. If declare is able to
> recognize assignments separated by spaces, I think it would have not
> been difficult avoiding $b to be evaluated since it's really not meant
> to be. It clearly is a simple form of assignment. Imo even if declare
> is a builtin (which is actually a little special over a normal one), it
> should have just emulated behavior of normal assignments and did nothing
> more than it besides declaring the type (and optionally have some other
> features not related to assignment).
It does implement `emulated behavior of normal assignments'. The question
is whether or not it should do that after having had its arguments undergo
one round of word expansion.
> (But I think those who used to recommend using declare as a general tool
> for assigning values remotely over evil eval would love it since
> it makes assignments like `declare -g "$var=$something"` possible
> which naturally should have been illegal.)
Why should this have been illegal? Even Posix acknowledges that constructs
like `export $one=$two' are valid. The question is what to do about
compound assignment.
> Anyhow, this problem would only happen if a variable in a specific
> scope (and only in that scope) has already been set previously as an
> array and it doesn't always happen if you write your scripts well.
>
>> It may be worth recommending people do a "unset var" before
>> doing a "declare [-<option>] var"
>
> I actually find it better to mention that on a simple assignment like
> declare var=$something, var's type doesn't change if it has already been
> declared previously as an array.
As I mentioned in a previous message, there's no reason for a script writer
to expect that `declare x=y' unsets x. Assignment without using `declare'
doesn't. Maybe it is worth saying that nothing will change an array
variable's type, though it's possible to promote a variable to an array.
--
``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/
