Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: Bug with associative array and P flag?
- X-seq: zsh-workers 19709
- From: Oliver Kiddle <okiddle@xxxxxxxxxxx>
- To: Jonathan Hankins <jonathan-hankins@xxxxxxxxxxxxxx>
- Subject: Re: Bug with associative array and P flag?
- Date: Tue, 30 Mar 2004 19:21:23 +0200
- Cc: zsh-workers@xxxxxxxxxx
- In-reply-to: <200403292014.40540.jonathan-hankins@xxxxxxxxxxxxxx>
- Mailing-list: contact zsh-workers-help@xxxxxxxxxx; run by ezmlm
- References: <200403292014.40540.jonathan-hankins@xxxxxxxxxxxxxx>
Jonathan Hankins wrote:
> Below are two examples of using the P flag to variable expansion to access an
> array indirectly. When using a regular array (foo), this works correctly.
> However, when using an associative array in the same way, I get the value of
> the first (alphabetically? randomly?) key (animal) regardless of the key I
> use. Should the P flag work with the associative array in the same way as it
> does with the regular array?
This isn't so much a bug as a design limitation. It has nothing in
particular to do with the P flag. Note that:
print ${${bar}[color]}
would print `cat' just like ${${(P)ref}[color]}
Note also:
% print $bar
cat apple red
What is happening is that the inner expansion is returning this as an
array of three items. Using [color] as an index is then equivalent to
using [0] because it is taken as a regular array index and hence a math
expression. Note the difference if you assign color=2 first. Ideally,
we would need an explicit (v) for it to work this way.
For this to work, I think we will need the long overdue major changes
to the parameter code. That's because I don't think the nested
expansion code handles anything other than scalars and arrays for the
nested parameters.
Oliver
Messages sorted by:
Reverse Date,
Date,
Thread,
Author