Zsh Mailing List Archive
Messages sorted by: Reverse Date, Date, Thread, Author

Re: Parameter flags and subscripts and references



> There are many issues with references to subscripted variables. I worked on that a few months ago. I'll have to resume that work.

Most of these are probably very rarely used cases, so I wouldn't call
this urgent.

From what I remember it looked more severe than that but I will have to double check. I will comment more once I have resurrected my previous work.

$r2 is implicitly doing ${(!)r1[2]} because of the "stop at
subscripts" behavior.  This could at least be documented (note to
self).

This looks wrong to me. In my opinion "print $r2" should return the same as "print ${r1[2]}". This would require NOT "stop at subscripts". My impression was that it could be achieved but I don't have working code. So, it could also turn out to be much more difficult than I thought. As the related code touches the same areas as the simplification patch, I will wait until that one is committed in one form or another to avoid a nightmarish merge.

This originated from Daniel's question:
> Should ${(t!)foo} expand to "nameref-scalar" whenever ${parameters[foo]} does?

Maybe the answer is that ${parameters[foo]} should *never* expand to
"nameref-scalar" and should just stop at "nameref" like (t!) does,
regardless of what "foo" represents.

Obviously that would be less informative but it would be consistent. And you could still get the lost information with  ${parameters[${(!)foo}]} (although only if the referent isn't hidden in the current scope). I wouldn't change anything right now. Indeed, if we can eliminate "stop at subscripts", the current behavior might become consistent but if "stop at subscripts" remains in place, your proposal might be the better alternative.

Philippe


On Fri, Nov 14, 2025 at 5:05 AM Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> wrote:
On Thu, Nov 13, 2025 at 6:22 PM Philippe Altherr
<philippe.altherr@xxxxxxxxx> wrote:
>>
>> print $parameters[nr]
>> nameref-nameref
>>
>> This happens because getpmparameter() presumes that gethashnode2() and
>> getparamnode() will return different results, but resolve_nameref()
>> called from getparamnode() recognizes that a subscripted referent must
>> be the stopping point, and so returns its input.
>
> There are many issues with references to subscripted variables. I worked on that a few months ago. I'll have to resume that work.

Most of these are probably very rarely used cases, so I wouldn't call
this urgent.

Related:

% array=(a b c)
% typeset -n r1=array
% print ${r1[2]}
b
% typeset -n r2='r1[2]'
% print $r2
r

$r2 is implicitly doing ${(!)r1[2]} because of the "stop at
subscripts" behavior.  This could at least be documented (note to
self).

>> The question is, what should the result be?
>
> Given that "$parameters[path[2]]" expands to the empty string, I would expect "$parameters[nr]" to expand to just "nameref". If we ever change "parameters" to return some non-empty value "FOO" for the former then the latter should return "nameref-FOO".

This originated from Daniel's question:
> Should ${(t!)foo} expand to "nameref-scalar" whenever ${parameters[foo]} does?

Maybe the answer is that ${parameters[foo]} should *never* expand to
"nameref-scalar" and should just stop at "nameref" like (t!) does,
regardless of what "foo" represents.


Messages sorted by: Reverse Date, Date, Thread, Author