Re: Inconsistency of GLOB_ASSIGN

[Peter Stephenson <p.w.stephenson@xxxxxxxxxxxx>]

On Wed, 26 Nov 2014 21:57:25 -0800
Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> wrote:
> Yes, I know the reason is that "Config" got expanded first and then taken
> as a variable name in arithmetic evaluation, therefore defaulting to the
> value 0 which was assigned to x.

Ick.

> Still, the following seems wrong to me:
> 
> torch% integer x
> torch% typeset -p x
> typeset -i x=0
> torch% x=*.h
> zsh: bad floating point constant

Yes, I think that if there are expansions using GLOB_ASSIGN --- for which I
think the test that the result is different from the original is good
enough --- we ought to treat it as either a scalar or an array
assignment.  The mixture is stupid.

It would be neater always to do an array assignment, in fact, but
the traditional behaviour is that if there was only one result the
assignment is scalar, and GLOB_ASSIGN is really there only for
tradition.

Arguably we should look at the type of the destination and if it's
numeric not do a glob at all.  I'd be happy with that, since:

integer x
x=3*3

probably doesn't mean "look for files beginning and ending in 3", but maybe it's making the whole thing even more complicated.

I will try to think of a prize to give anyone who can make any language
other than zsh report a floating point error when assigning an array to
an integer.

pws