Re: [PATCH] Fix crash on unset-through-nameref

[Stephane Chazelas <stephane@xxxxxxxxxxxx>]

2024-03-04 15:18:06 -0800, Bart Schaefer:
> On Mon, Mar 4, 2024 at 11:34 AM Stephane Chazelas <stephane@xxxxxxxxxxxx> wrote:
> >
> > 2024-03-04 00:39:30 -0800, Bart Schaefer:
> > >
> > > Try removing this line from the patch:
> > >
> > > +    pm->node.flags |= PM_DECLARED;
> >
> > $ ./Src/zsh -c 'myunset() { typeset -n v=$1; unset v; }; export x=1; myunset x; typeset -p x; x=2; typeset -p x'
> > export x=2
> >
> > It still retained its export attribute.
> 
> This gets messy because POSIX says that's exactly what's supposed to
> happen when unsetting an export, even though in native zsh it normally
> doesn't work that way.

No, I think you're confusing with:

export foo

Which is meant to give the export attribute to foo without
giving it a value (so the variable will end up in the
environment of executed command if ever its assigned in the
future but not until then).

unset foo (or better unset -v foo as POSIX allows bash's
behaviour where that could unset a function instead) is required
to clear the value and export attribute.

unset is the only way to unexport a variable in POSIX shells.


> You'll note it also didn't say
>   typeset: no such variable: x
> 
> ... because there is no provision in the parameter implementation for
> a global to occupy a table slot and yet to appear not to exist.
> 
> This is one of the reasons your desire for "create it an as unset at
> the time a nameref mentions it" has inherent problems.

I was suggesting a "unset (and undeclared then) but named ref"
(and refcount if needed for garbage collection) flag for that in
a separate message, but I have no idea whether that'd be
sufficient or feasible.

I hate to say this but it seems to me that if this kind of issue
is not fixable, then it would likely be preferable (from a
consistency PoV at least) to go for bash/mksh dumber approaches
where namerefs are just plain scalar variables containing the
name of another variable (or other lvalue) and having the target
variable resolved any time the nameref is assigned/referenced
(in whatever scope that happens to be).

You'd still need to namespace your variables in functions using
namerefs, even more so, but at least it would be more consistent
and we wouldn't have to list all the special cases that work or
don't work in the documentation

BTW, speaking of "other lvalue", see also:

$ ksh -c 'typeset -n a="b[n++]"; typeset -p n; b=(); a=a a=b a=c; typeset -p b n'
n=2
typeset -a b=([1]=c)
n=2
$ mksh -c 'typeset -n a="b[n++]"; typeset -p n; b=(); a=a a=b a=c; typeset -p b n'
set -A b
typeset b[0]=a
typeset b[2]=b
typeset b[4]=c
typeset n=6
$ bash -c 'typeset -n a="b[n++]"; typeset -p n; b=(); a=a a=b a=c; typeset -p b n'
bash: line 1: typeset: n: not found
declare -a b=([0]="a" [1]="b" [2]="c")
declare -- n="3"
$ ./Src/zsh -c 'typeset -n a="b[n++]"; typeset -p n; b=(); a=a a=b a=c; typeset -p b n'
zsh:typeset:1: no such variable: n
typeset -a b=( a '' b '' c )
typeset -i n=6

Which suggests the lvalue is still evaluated by zsh at every assignment at
least.

(see also
https://unix.stackexchange.com/questions/640687/prevent-command-substitution-from-running-when-declaring-a-variable/640695#640695
where namerefs are abused to have a variable with a dynamic
value).

-- 
Stephane