set -A

set -A

[Paul Ackersviller]

I think this is a bug in all versions, but if there's some reason
the behaviour could be considered correct, it'd be nice if it at
least worked like ksh in emulation mode.  I recently had some trouble
getting a ksh script to work properly in zsh, as illustrated by:

unset arr
set -A arr "${arr[@]}" first
[ ${#arr[@]} = 2 ] && echo "arr[0]='${arr[0]}' arr[1]='${arr[1]}'"

Note the null entry on the start of the array.  I believe the above
should work as in ksh, and consistently with positional parameters,
like this:

set --
set -A arr "$@" first
echo arr now has only ${#arr[@]} element

Secondly, I have more of an observation than a bug report that better
fits the subject since it has to do with parsing after the -A of set.
	set -A arr -x
puts -x into the beginning of the array, whereas ksh treats the -x as
an option to set instead.  In ksh
	set -A arr -- -x
would get around that, but the same command in zsh now put the -- into
the array.  I think either way could be considered correct, but it
would be nicer if the same command had the same effect in both shells.

-- 
Paul Ackersviller

Re: set -A

[Bart Schaefer]

On Feb 6,  7:01pm, Paul Ackersviller wrote:
} Subject: set -A
}
} unset arr
} set -A arr "${arr[@]}" first
} [ ${#arr[@]} = 2 ] && echo "arr[0]='${arr[0]}' arr[1]='${arr[1]}'"
} 
} Note the null entry on the start of the array.

This really has nothing to do with "set -A".

If you've unset arr, then arr is not an array, and hence ${arr[@]} is
not an array either, and therefore "${arr[@]}" does not behave like
an array; rather, it behaves like a string, so putting it in double
quotes yields the empty string.

} I believe the above should work as in ksh, and consistently with
} positional parameters

Doesn't follow.  $@ cannot be unset, it can only be set to the empty
array.  This example ...

} set --
} set -A arr "$@" first
} echo arr now has only ${#arr[@]} element

... really corresponds to:

arr=()
set -A arr "${arr[@]}" first
echo arr now has only ${#arr[@]} element

} [...] it'd be nice if it at least worked like ksh in emulation mode.

This is a clash with zsh's usage where subscripts on a string yeild
substring slices.  The substring slice [@] is the entire string, so
${string[@]} == ${string}.  We were under the impression that this
could not possibly clash with a valid ksh script, because no working
ksh script could rely upon subscripting a string.

We may have to rethink that.

Re: set -A

[Peter Stephenson]

"Bart Schaefer" wrote:
> On Feb 6,  7:01pm, Paul Ackersviller wrote:
> } Subject: set -A
> }
> } unset arr
> } set -A arr "${arr[@]}" first
> } [ ${#arr[@]} = 2 ] && echo "arr[0]='${arr[0]}' arr[1]='${arr[1]}'"
> } 
> } Note the null entry on the start of the array.
> 
> This really has nothing to do with "set -A".
> 
> If you've unset arr, then arr is not an array, and hence ${arr[@]} is
> not an array either, and therefore "${arr[@]}" does not behave like
> an array; rather, it behaves like a string, so putting it in double
> quotes yields the empty string.

But the `@' subscript is not documented to do anything useful for
strings, nor can I see why anyone would assume it was useful in that
case, nor, if they *did* think, that why they would assume that it
produced a null string instead of the usual elision of the argument.  (I
haven't put that very well.)

I think we could safely and consistently have a non-existent parameter
treated as an array in this special case without any negative impact.

The main problem with doing anything is that this part of the code is
particularly ghastly and I shudder at going anywhere near it.

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR Ltd., Science Park, Milton Road,
Cambridge, CB4 0WH, UK                          Tel: +44 (0)1223 692070


**********************************************************************
The information transmitted is intended only for the person or
entity to which it is addressed and may contain confidential 
and/or privileged material. 
Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by 
persons or entities other than the intended recipient is 
prohibited.  
If you received this in error, please contact the sender and 
delete the material from any computer.
**********************************************************************

Re: set -A

[Bart Schaefer]

On Feb 7, 10:48am, Peter Stephenson wrote:
}
} "Bart Schaefer" wrote:
} > If you've unset arr, then arr is not an array, and hence ${arr[@]} is
} > not an array either, and therefore "${arr[@]}" does not behave like
} > an array; rather, it behaves like a string, so putting it in double
} > quotes yields the empty string.
} 
} But the `@' subscript is not documented to do anything useful for
} strings

That's not strictly true.  The docs say, in consecutive paragraphs:

----------
A subscript of the form `[*]' or `[@]' evaluates to all elements of an
array; there is no difference between the two except when they appear
within double quotes. [...]

Subscripting may also be performed on non-array values, in which case
the subscripts specify a substring to be extracted.
----------

} nor can I see why anyone would assume it was useful in that case

It does NOT say that subscripting non-array values is limited to using
integer ranges; it just says "subscripting may also be performed."

} nor, if they *did* think, that why they would assume that it
} produced a null string instead of the usual elision of the argument.
} (I haven't put that very well.)

You put it well enough, and that last is a valid point.  Since for
foo=(x y z) we have "$foo[@]" equivalent to "x" "y" "z", then given
foo=xyz, should the expectation be that "$foo[@]" is "x""y""z" ?
(Note no word breaks between the quoted substrings.)  That might have
some pretty bizarre side-effects for nested expansions.

} I think we could safely and consistently have a non-existent parameter
} treated as an array in this special case without any negative impact.

It's actually worse than that, though, because ksh treats ALL parameters
as arrays -- in ksh, foo=xyz is the same as foo=(xyz) in zsh, and the
fiction of string variables is maintained by making $foo a reference to
${foo[0]}.  So when KSH_ARRAYS is set, ${foo[1]} (or any number greater
than zero) ought to produce an empty result when used on a scalar.

Re: set -A

[Peter Stephenson]

"Bart Schaefer" wrote:
> } But the `@' subscript is not documented to do anything useful for
> } strings
> 
> That's not strictly true.  The docs say, in consecutive paragraphs:
> 
> ----------
> A subscript of the form `[*]' or `[@]' evaluates to all elements of an
> array; there is no difference between the two except when they appear
> within double quotes. [...]
> 
> Subscripting may also be performed on non-array values, in which case
> the subscripts specify a substring to be extracted.
> ----------
> 
> It does NOT say that subscripting non-array values is limited to using
> integer ranges; it just says "subscripting may also be performed."

The simple-minded reading would therefore be that the [@] has the same
behaviour for strings as for arrays --- i.e. whether the parameter
happens to be unset or not, and whether or not KSH_ARRAYS is in effect.
Does that break anything if KSH_ARRAYS isn't set?  (Presumably it
doesn't break anything unless it relies on `undefined behaviour', hur
hur.  But I don't think we can be that sanguine about the zsh
documentation, c.f. hitherto the undocumented set -A behaviour.)

> It's actually worse than that, though, because ksh treats ALL parameters
> as arrays -- in ksh, foo=xyz is the same as foo=(xyz) in zsh, and the
> fiction of string variables is maintained by making $foo a reference to
> ${foo[0]}.  So when KSH_ARRAYS is set, ${foo[1]} (or any number greater
> than zero) ought to produce an empty result when used on a scalar.

Yes, that seems inevitable.

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR Ltd., Science Park, Milton Road,
Cambridge, CB4 0WH, UK                          Tel: +44 (0)1223 692070


**********************************************************************
The information transmitted is intended only for the person or
entity to which it is addressed and may contain confidential 
and/or privileged material. 
Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by 
persons or entities other than the intended recipient is 
prohibited.  
If you received this in error, please contact the sender and 
delete the material from any computer.
**********************************************************************