Re: More rabbit-holes with unset variables

[Bart Schaefer <schaefer@brasslantern.com>]

On Wed, Nov 25, 2020 at 2:17 PM Felipe Contreras
<felipe.contreras@gmail.com> wrote:
>
> [quoting an article from the posix tracker]
>   The variable whose name is specified shall be created as a local
> variable with name "name". It
>   shall inherit its initial value, as well as the exported and
> readonly flags, from the variable
>   with the same name in the surrounding dynamic scope if there is one;
> otherwise, the variable is
>   initially unset. Then, if "=word" is provided, the value of that
> local variable shall then be set
>   to word.
>
> So, the variable is initially unset, *unless* "=word" is provided.
>
> Do you think anyone objected to that behavior?

Is there a newer version of the standard than V4 from 2018, which is
the latest I can find online?

"Local variables within a function were considered and included in
another early proposal (controlled by the special built-in local), but
were removed because they do not fit the simple model developed for
functions and because there was some opposition to adding yet another
new special built-in that was not part of historical practice.
Implementations should reserve the identifier local (as well as
typeset, as used in the KornShell) in case this local variable
mechanism is adopted in a future version of this standard."

So the language you're quoting was rejected, though not for that
specific reason.

In fact, unless the notion of typed variables (integer, array, etc.)
is excluded, that language is ambiguous, because (as I've mentioned
elsewhere) the behavior of an "unset" variable in other contexts (such
as assignment) is that it takes on the attributes from the assignment;
so a the only useful "declared but not set" variable is a simple
scalar.

I'll note that posix defines null as "" (double-quoted empty string)
although it requires a careful reading to find that.