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

[Bart Schaefer <schaefer@brasslantern.com>]

On Tue, Mar 5, 2024 at 12:19 AM Stephane Chazelas <stephane@chazelas.org> wrote:
>
> 2024-03-04 15:18:06 -0800, Bart Schaefer:
> > On Mon, Mar 4, 2024 at 11:34 AM Stephane Chazelas <stephane@chazelas.org> wrote:
> > >
> > > 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

I'm referring to comments in the C code, e.g.:

     * POSIXBUILTINS horror: we need to retain the 'readonly' or 'export'
     * flags of an unset parameter.
[...]
    if (isset(POSIXBUILTINS)) {
[...]
        /* This is handled by createparam():
        if (usepm && (pm->node.flags & PM_EXPORTED) && !(off & PM_EXPORTED))
            on |= PM_EXPORTED;
        */

> 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

That is in fact exactly how it works, with the addition now that -u
makes it skip upward one scope before resolving.

> (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).

Although I wasn't aware of that discussion, I had already thought of that:

  When RNAME includes an array subscript, the subscript expression is
  interpreted at the time ${PNAME} is expanded.  Any form of subscript is
  allowed, including those that select individual elements, substrings of
  scalar strings, or multiple elements as with array slices or the '(i)',
  '(I)', '(r)', '(R)' and '(w)' subscript flags.  However, the subscript
  is evaluated with the NO_EXEC option in effect, so command substitution
  and other similar constructs produce no output, although are not
  syntactically excluded.