${(A)=xxx} - second go - now real bug.

${(A)=xxx} - second go - now real bug.

[Andrej Borsenkow]

Reading docs once more I noted this:

A
     Create an array parameter with ${...=...}, ${...:=...} or
     ${...::=...}.  If this flag is repeated (as in AA), create an
     associative array parameter.  Assignment is made before sorting or
     padding.  The NAME part may be a subscripted range for ordinary
     arrays; the WORD part *must* be converted to an array, for example
     by using ${(AA)=...} to activate word splitting, when creating an
     associative array.

Please, note the last sentence. It implies, that in case of array/hash
assignment the word is treated as in array assignment - that is, ${(A)foo=bar
baz} is basically the same as foo=(bar baz). At least, I find this natural and
useful. And I have a feeling, that it was once so. Currently we have:

bor@itsrm2:~%> : ${(AA)foo::=bar baz}
zsh: bad set of key/value pairs for associative array

bor@itsrm2:~%> print -l $foo

bor@itsrm2:~%> print ${(t)foo}
association
bor@itsrm2:~%> unset foo
bor@itsrm2:~%> : ${(A)foo::=bar baz}
bor@itsrm2:~%> print -l $foo
bar baz
bor@itsrm2:~%> print ${(t)foo}
array


I suggest changing it to the described. That is,

${foo=bar} - the same as foo=bar (with blanks quoted, 'course)
${(A)foo=bar}, ${(AA)foo=bar} -
             the same as foo=(bar)

A good question is, if we should do globbing in above cases. I dare to say, that
it may be useful ... following the usual rules. That is, no globbing in
${foo=bar} and normal globbing in ${(A)foo=bar}

Additional suggestion - what about iterpreting the (A) and (AA) flags in
${(A):-bar} ? The main reason is, currently it is always producing scalar; but
there are cases (mostly globbing) where I'd like to have array. Again, splitting
is _not_ the same. This would allow to use

${(A):-*.txt}

to get a list of files instead of current

${(f)"$(print -l *.txt)"}

that always has a problem with new lines in file names. And it is more simple
and arguably faster.

And final question: how should the following (from parameter expansion) be
interpreted:

s:STRING:
     Force field splitting (see the option SH_WORD_SPLIT) at the
     separator STRING.  Splitting only occurs in places where an array
     value is valid.

I mean the last sentence?

regards

/andrej

Re: ${(A)=xxx} - second go - now real bug.

[Peter Stephenson]

"Andrej Borsenkow" wrote:
> Reading docs once more I noted this:
> 
> A
>      Create an array parameter with ${...=...}, ${...:=...} or
>      ${...::=...}.  If this flag is repeated (as in AA), create an
>      associative array parameter.  Assignment is made before sorting or
>      padding.  The NAME part may be a subscripted range for ordinary
>      arrays; the WORD part *must* be converted to an array, for example
>      by using ${(AA)=...} to activate word splitting, when creating an
>      associative array.
> 
> Please, note the last sentence. It implies, that in case of array/hash
> assignment the word is treated as in array assignment - that is, ${(A)foo=bar
> baz} is basically the same as foo=(bar baz). At least, I find this natural an
> d
> useful. And I have a feeling, that it was once so.

I think you've missed the sense of the = after the (AA) in that
substitution, which is to turn on word-splitting: ${(AA)=foo::=a b}.  As
far as I know it's always been like that.  (=, ~, ^ would have been flags
if they'd been invented later, it's rather a mess to say the least.)

But I don't really like this way of doing things anyway, since it's getting
round lexing and parsing in slightly odd ways.  It would be nice to be able
to do this properly, though.  We really need a syntactically sensible way
of generating expansions arbitrarily deeply inside other expressions
without forking.  The suggestion for doing globbing here in ordinary cases
doesn't fit in with the shell expansion order, which is that globbing is
only performed on the final result of parameter expansion (assuming
globsubst, of course).

The error message has got too many newlines, which is annoying me.

--- Src/params.c~	Tue Jul  6 13:31:11 1999
+++ Src/params.c	Wed Jul  7 17:29:26 1999
@@ -1905,7 +1905,7 @@
 
     if (alen % 2) {
 	freearray(val);
-	zerr("bad set of key/value pairs for associative array\n",
+	zerr("bad set of key/value pairs for associative array",
 	     NULL, 0);
 	return;
     }

-- 
Peter Stephenson <pws@ibmth.df.unipi.it>       Tel: +39 050 844536
WWW:  http://www.ifh.de/~pws/
Dipartimento di Fisica, Via Buonarroti 2, 56127 Pisa, Italy

RE: ${(A)=xxx} - second go - now real bug.

[Andrej Borsenkow]

>
> ${foo=bar} - the same as foo=bar (with blanks quoted, 'course)
> ${(A)foo=bar}, ${(AA)foo=bar} -
>              the same as foo=(bar)
>

Some more question.

Documentation says "word". It prohibits ${foo=bar baz} because ``bar baz'' is
not a word. Either documentation or shell should be corrected :-)

Assuming that blanks are valid, I _do_ mean ${(A)foo=$bar $baz} should be the
same as foo=($bar $baz):

bor@itsrm2:~%> foo='bar baz'
bor@itsrm2:~%> bar='baz bad'
bor@itsrm2:~%> baz=($foo $bar)
bor@itsrm2:~%> print -l $baz
bar baz
baz bad

Note, that neither $foo nor $bar are word splitted. It is not the same, as first
compute ``$foo $bar'' and split it.

If blanks are not valid - then it is much more simple. We only have to make sure
that arrays are preserved and not converted to scalars.

How is ``bar'' in "${(A)foo=bar}" interpreted? Is it quoted or not? That is
important to decide, what value ``foo'' gets (but the value of substitution
won't change :-)

/andrej

Re: ${(A)=xxx} - second go - now real bug.

[Bart Schaefer]

On Jul 7,  7:32pm, Andrej Borsenkow wrote:
} Subject: ${(A)=xxx} - second go - now real bug.
}
}      [...] the WORD part *must* be converted to an array, for example
}      by using ${(AA)=...} to activate word splitting, when creating an
}      associative array.
} 
} Please, note the last sentence. It implies, that in case of array/hash
} assignment the word is treated as in array assignment - that is,
} ${(A)foo=bar baz} is basically the same as foo=(bar baz). At least, I
} find this natural and useful. And I have a feeling, that it was once
} so.

Read that sentence again, and note the word "converted."  It has *never*
been the case that ${(A)foo=bar baz} is the same as foo=(bar baz).

} I suggest changing it to the described. That is,
} 
} ${foo=bar} - the same as foo=bar (with blanks quoted, 'course)
} ${(A)foo=bar}, ${(AA)foo=bar} -
}              the same as foo=(bar)

I looked at this a bit when we had the last go-round about ${(A)foo=}.
The problem is that
	foo=(bar baz)
can be determined at lex time to be an array assignment by recognizing the
parens, whereas
	${(A)foo=bar baz}
lexes as a parameter expansion.  The lexer doesn't know that (A) is there,
and therefore can't break "bar baz" into words; it reads the entire ${...}
as a single string, which it is then up to the parameter expansion code to
interpret.  It has always been like this.

} A good question is, if we should do globbing in above cases. I dare to say,
} that it may be useful ...

Yes, it would, and that is in fact the reason that I looked into the issue
before.  It doesn't work for the same reason; the entire ${...} has already
been tokenized by the time it gets to the parameter code.

It *might* be possible to undo the tokenization and re-parse the string,
but that would involve invoking the lexer from the parameter code, which
I was not prepared to undertake.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Re: ${(A)=xxx} - second go - now real bug.

[Bart Schaefer]

On Jul 7,  7:50pm, Andrej Borsenkow wrote:
} Subject: RE: ${(A)=xxx} - second go - now real bug.
}
} Some more question.
} 
} Documentation says "word". It prohibits ${foo=bar baz} because ``bar baz'' is
} not a word. Either documentation or shell should be corrected :-)

"bar baz" *is* a word.  The spaces are not significant when inside ${...};
the documentation is telling you how the expression is going to be parsed.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com