Re: Bug with unset variables

[Felipe Contreras <felipe.contreras@xxxxxxxxx>]

On Tue, Nov 17, 2020 at 2:54 PM Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> wrote:
>
> On Mon, Nov 16, 2020 at 11:42 AM Felipe Contreras
> <felipe.contreras@xxxxxxxxx> wrote:

> > 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

So?

Is it *functionally* the same or not?

> 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:

This is a smoke screen.

Notions don't change the behavior of the code above.

It either is *functionally* the same, or it isn't.

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

My statement was not an aphorism, but even if it was; that doesn't
change the fact that it's true.

I was not the one that brought history into the thread. You are the
one that brought the history, which by definition cannot be changed.

If now you are saying there's no point in talking about something that
can't be changed (the past), then fine by me.

> > KSH_TYPESET does something else that not even ksh does. But another
> > option might make sense.
>
> Which particular something are you thinking of?

My understanding of that option is that it changed the behavior of this:

    typeset var=$(echo one word)

To this:

  builtin typeset var=$(echo one word)

In other words:

  typeset var=one word

But that's not what ksh does, at least the version I have installed.

Anyway, I see now that it's obsolete, so in theory it could be reused.

Cheers.

-- 
Felipe Contreras