Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: set -A
- X-seq: zsh-workers 18222
- From: Peter Stephenson <pws@xxxxxxx>
- To: zsh-workers@xxxxxxxxxx
- Subject: Re: set -A
- Date: Tue, 11 Feb 2003 10:38:02 +0000
- In-reply-to: "Oliver Kiddle"'s message of "Tue, 11 Feb 2003 09:45:38 +0100." <8132.1044953138@xxxxxxxxxxxxxxxxxxxx>
- Mailing-list: contact zsh-workers-help@xxxxxxxxxx; run by ezmlm
Oliver Kiddle wrote:
> I'm inclined to agree that this is wrong. It would seem more logical to
> me for an unset variable to be interpreted as an empty array when
> retrieved in array context.
>...
> I've been aware of this for some while and had intended to change it if
> I ever have time to finish work on the parameter code. Would changing
> it break much? It would improve bash/ksh compatibility.
I suspect it would improve matters in the particular case of `[@]' --- I
see no occasion when someone would deliberately use that in the
expectation it caused "$foo[@]" to turn into a zero-length string for an
empty $foo of any type. However, note there is in general no such thing
as `array context' in zsh, so we need to be careful with other subscripts.
> A similar thing which I find annoying is
> that local defines parameters to be scalar by default instead of
> leaving their type undefined causing similar empty element problems.
There's no such thing as an undefined type for a declared parameter,
either, nor is it clear what that would mean. You have to declare it with
a particular type. You need to declare it as `local -a' if you want it
to behave as an array. I think the problem is few people have yet got
into the habit of doing this (though increasing use of += makes it more
necessary).
--
Peter Stephenson <pws@xxxxxxx> 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.
**********************************************************************
Messages sorted by:
Reverse Date,
Date,
Thread,
Author