Re: More rabbit-holes with unset variables

[Bart Schaefer <schaefer@brasslantern.com>]

On Thu, Nov 26, 2020 at 1:31 PM Felipe Contreras
<felipe.contreras@gmail.com> wrote:
>
> And you don't find it inconsistent that the internal value is
> *different* from the exported value?

That's a loaded question, because to answer it requires conceding that
there exists an exported value from which the internal value differs.
There's no way to "see" the export namespace without forking an
external process, so only the internal value matters.

That internal value exists for the sole purpose of recording the fact
that two different namespaces need to be synchronized whenever either
of them changes.  The "difference" occurs because neither namespace
has changed yet.  The fact that there is no first-class "not defined"
value that can be employed for this purpose is the same issue that got
us into this whole discussion to begin with.

We're back to the point that from inside the shell, the only place
where that difference is a distinction is when you explicitly inquire
about the "not defined" state, and I'm already looking for a solution
to that.

> Plus this:
>
>   typeset -x FOO
>
> Is different than this:
>
>   typeset -x FOO=""
>
> ?

It also differs from

typeset -i FOO

which internally sets FOO=0 but doesn't export it until something
changes.  Diving into how zsh represents the relationship between the
internal and exported namespaces is a whole other ball of wax and is
why I tried to keep it out of scope before Oliver brought it up.