Re: BUG: zsh-3.1.5-pws-14: parameter expansion not working properly

["Bart Schaefer" <schaefer@xxxxxxxxxxxxxxxx>]

On May 7,  1:51pm, Peter Stephenson wrote:
} Subject: Re: BUG: zsh-3.1.5-pws-14: parameter expansion not working proper
}
} Sven Wischnowsky wrote:
} > 
} > [ There is a little patchlet below. I don't suggest using it to
} >   everyone just now, it's just that I can think about this better when 
} >   I have cod to play with. Didn't have the time for this yesterday. ]
} 
} Is there any agreement on this patch (6046) to introduce the variable
} mult_isarr to keep track of whether a nested parameter substitution returns
} an array?

I think it's more sensible behavior than what's happening now.  It's a
little less likely to break scripts written for 3.0.x, too.

} If so, what documentation changes are needed (which might help
} tell everyone else what it's doing)?

We'd have to revise the "parameter expansion rules" section that you
added.  In particular, the latter part of this:

  1. *Nested Substitution*
     If multiple nested `${...}' forms are present, substitution is
     performed from the inside outwards.  At each level, the
     substitution takes account of whether the current value is a
     scalar or an array, whether the whole substitution is in double
     quotes, and what flags are supplied to the current level of
     substitution; the flags are not propagated up to enclosing
     substitutions.  The value passed back to an enclosing substitution
     is always an array, which however will consist of one word if the
     value was not itself an array.  All the following steps take place
     where applicable at all levels of substitution.

Becomes (see Sven's note):
                                        ... the current level of
     substitution, just as if the nested substitution were the
     outermost.  The flags are not propagated up to enclosing
     substitutions; nor are arrays joined into strings, nor strings
     split into arrays, except as indicated by the flags at the
     current level as adjusted for quoting.  All the following steps
     take place where applicable at all levels of substitution.

I don't know whether we'd want to add something like:

     Note that, unless the (P) flag is present, the flags and any
     subscripts at each enclosing substitution apply directly to the
     value of the nested substitution.

Then as Sven mentioned:

  2. *Parameter Subscripting*
     If the value is a raw parameter reference with a subscript, such
     as ${VAR[3]}, the effect of subscripting is applied directly to
     the value of the parameter.  Subscripts are evaluated left to
     right; each second and succeeding subscript applies to the value
     yielded by the previous subscript.  Thus, if VAR is an array,
     ${VAR[1][2]} is the second character of the first word, but
     ${VAR[2,4][2]} is the entire third word (the second word of the
     range of words two through four of the original array).

Perhaps an example should note that

     ${foo[2,4][2]} == ${${foo[2,4]}[2]}		(No quotes!)
     ${${foo[2,4]}[2]} != "${${foo[2,4]}[2]}"		(Quotes matter)
     ${${foo[2,4]}[2]} == "${${(@)foo[2,4]}[2]}"	((@) matters)

And finally, the example changes Sven described.

} And what about the other glitch that was noticed, that a single word
} array is always turned into a scalar (currently around line 1471 in
} subst.c), do we get rid of that for consistency?

I tried deleting that and got a core dump elsewhere in subst.c.  There's
a loop over the array that assumes index 1 must not be null because it's
not possible (when the line-1471-code is present) to get there with a 1-
element array.  I haven't worked out whether there are other consequences
to stopping that loop sooner.

I think we should correct it, but there's almost certainly some reason
for it, perhaps now lost in the mists of time.

On May 7,  3:36pm, Sven Wischnowsky wrote:
} Subject: Re: BUG: zsh-3.1.5-pws-14: parameter expansion not working proper
}
} About changes needed in the shell code: I once had this patch in my
} version, of course. I used as a normal working shell and the
} completion functions at least didn't suffer from it. But they (almost?)
} always use the `(@)' flag on every level and the behavior for that
} wasn't changed. I haven't tried all example shell code stuff we have,
} but a quick `grep @ ...' looks good (we don't use subscripts on nested 
} parameter expansion very often, it seems).

Right.

The only good alternatives at this point are probably [a] go back to the
3.0 behavior of (@), or [b] leave it the way this mult_isarr patch leaves
it.  Can anyone think of something in between that makes sense?

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