Re: [Language Design] How should references to localized special parameters behave?

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Tue, Aug 4, 2026 at 12:42 PM Philippe Altherr
<philippe.altherr@xxxxxxxxx> wrote:
>
> typeset -n home=HOME
> HOME=/bin; cd; pwd
> function fn {
>   typeset HOME=/usr; cd; pwd
>   home=/var; cd; pwd
> }
> fn; cd; pwd
>
> In particular, what should the effect of the assignment "home=/var" be? Currently, it triggers a segmentation fault.

I think the easiest way out of this is for that assignment to be an error.

> The current implementation of "typeset HOME=/usr" moves the enclosing parameter into the current scope (i.e., assigns "locallocal" to "pm->level" where "pm" is the enclosing parameter's "Param" instance) and creates a pseudo parameter in the enclosing scope that stores the state of the enclosing parameter prior to the "typeset" (i.e., creates a "Param" instance that duplicates most of the fields of the enclosing parameter's "Param" instance). When the local scope is exited, the enclosing parameter is moved back to its original scope and its state is restored to its state prior to the "typeset" thanks to the values stored in the pseudo parameter, which is then discarded.
>
[...]
>
> Wdyt? Which way should Zsh adopt? Or do you see an alternative way?

What if builtin.c typeset_single() marked the pseudo parameter as
read-only and params.c scanendscope() undid that when restoring?  (Or
an equivalent.)

Requires a little care to avoid removing PM_READONLY from a special
that is expected to carry it, but it sidesteps the whole issue.  The
home=/var assignment would be an error before it became a segmentation
fault.