On Sat, Feb 25, 2017 at 4:12 PM, Bart Schaefer <schaefer@brasslantern.com>
wrote:

> Yes, this is a known / traditional behavior, and it somewhat regularly
> comes up in examples where a program has been tested only in the "more
> than one element" cases.
>
> The problem is that nesting ${${...}} "wants" to treat the inner ${...}
> as a scalar, and will do so unless something else forces it to be an
> array.  (f) doesn't accomplish that because $(dirs -v) produces only
> one line of output with the final newline stripped, so there is nothing
> for (f) to split on.  (@) won't accomplish it because it only means
> that things that are already arrays should remain so.
>
> So what can be done to force interpretation as an array here?  Unless
> someone else has a better solution, the answer is to forcibly assign
> the result to an array variable:
>
> print $((${${(z)${(Af)reply::="$(dirs -v)"}[-1]}[1]} + 1))
>

Good to know.  So in my original email the alternate example

 print $((${(z)${(fO)"$(dirs -v)"}[1][1]} + 1))

was this forcing it to an array or was it a fluke?  I assumed(bad
thing to do) that it had and "[1][1]" would then work properly.  It does
return the desired results for a single or multiple line output from
"dirs -v".


> Once we are expanding ${reply} rather than ${"$(dirs -v")} the array
> property is preserved and [-1] remains an array subscript instead of
> becoming a scalar string slice.
>
> A follow-up to this is going to zsh-workers.
>

I will forward this on to zsh-lovers.

Thanks for your help.

Jim