Re: Issue with VAR=foo cmd where VAR is a named reference

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Sun, May 3, 2026 at 2:05 AM Philippe Altherr
<philippe.altherr@xxxxxxxxx> wrote:
>
> I think that the following is fine:
>
> % typeset -n VAR=var; VAR=foo typeset -p VAR var; typeset -p VAR var
> typeset -n VAR=var
> typeset var=foo
> zsh:typeset:1: no such variable: var
> typeset -n VAR=var

Hmm, there's a complication here where you have to consider that (per
POSIX) some builtin commands preserve assignment to prefix environment
strings and some do not.  I don't immediately recall which category
"typeset" falls into.

> In other words, VAR=foo cmd, runs cmd with a parameter table where VAR's value has been temporarily changed to foo. If VAR happens to be a named reference, then it's the value of its referred variable that is changed.

I'm undecided about that.  It could be argued that
  VAR=foo command
should behave like
  () { local -x VAR=foo; command }
That is, VAR in the environment is entirely distinct from VAR in the
calling shell.  The difficult exception is the builtins that are
supposed to preserve assignment.  I suppose ksh behavior would be
worthwhile to investigate.

> Note that it's impossible to export arrays (because the environment only supports string values). The following simply exports nothing:
>
> % ARR=(foo) printenv | grep ARR=

In that case you have
  () { local -ax ARR=(foo); command }
so the no-array-exports rule kicks in.

> Exporting named references is in principle possible

I think that would be a bad choice.  For security reasons it should
not be possible to import a named reference, and other programs would
have no idea what to do with an environment instrumented by zsh for
the purpose.