Re: Bug with unset variables

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Mon, Nov 16, 2020 at 11:42 AM Felipe Contreras
<felipe.contreras@xxxxxxxxx> wrote:
>
> Declared is not the same as defined.

True, but in the shell language traditionally the only way to declare
a variable was to define it.  The exception was "export VAR" which has
so far been out of scope (ha ha) for this discussion, and later
"readonly VAR" which has limited use if VAR is not also defined.

> All languages we explored have the same notion (inside a function):

I'm just going to excerpt one of these because you claim they're all
the same ...

> Python:
>
>   foo = None
>   print(foo) # None
>   foo = "set"
>   foo = None # unset()
>   print(foo) # None
>
> Shell:
>
>   local foo
>   echo ${foo-nil} # nil
>   foo="set"
>   unset foo
>   echo ${foo-nil} # nil
>
> These are all functionally *exactly* the same. And that's an undeniable fact.

Except your examples are NOT the same.  Your shell example introduces
what amounts to a ternary test.  In shell

local foo
echo -n $foo

does not output "nil" or "undefined" or "None", it outputs NOTHING.
When you throw in ${foo-nil} you're effectively writing (pseudo code)

if the variable foo has no value
then substitute nil
else substitute the value of foo
fi

There literally is no concept of "not defined" in the shell language
outside of that implicit ternary; undefined is not a first-class
value.  You cannot write "if [[ $foo == undefined ]]" or any of the
similar comparisons that can be done in most if not all of the other
languages you assert are equivalent.  You can use $anydamnthing in the
shell anywhere an empty string can be used, without producing a null
dereference or similar error -- unless of course you've activated
NO_UNSET, which by the way:

nounset_error() {
  setopt localoptions nounset
  print $foo  # error
}
nounset_ok() {
  setopt localoptions nounset
  typeset foo
  print $foo  # not error
}

So the decisions made about the behavior of typeset have ramifications
beyond your use case.

> > > The most straightforward way is not necessarily the best way.

And the perfect is often the enemy of the good.  Let's stop throwing
aphorisms at each other, especially when they can't change decisions
made decades ago.

> KSH_TYPESET does something else that not even ksh does. But another
> option might make sense.

Which particular something are you thinking of?