Re: Bug with unset variables

[Felipe Contreras <felipe.contreras@xxxxxxxxx>]

On Mon, Nov 23, 2020 at 12:48 AM Bart Schaefer
<schaefer@xxxxxxxxxxxxxxxx> wrote:
>
> On Sat, Nov 21, 2020 at 5:49 PM Felipe Contreras
> <felipe.contreras@xxxxxxxxx> wrote:
> >
> > On Tue, Nov 17, 2020 at 2:54 PM Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> wrote:
> > >
> > > There literally is no concept of "not defined" in the shell language
> > > outside of that implicit ternary; undefined is not a first-class
> > > value.
> >
> > This is a smoke screen.
>
> This statement confuses me.   If you are insinuating that I'm raising
> a point solely for the purpose of obfuscating the discussion, then
> either (a) you haven't been paying attention to anything I've written
> on this mailing list in the past 25 years, or (b) I'm forced to
> believe you're actively attempting to be insulting.

No. A smoke screen screen doesn't have to be intentional.

I am saying X doesn't have anything to do with Y. You are arguing Y,
IMO all that is doing is diverting attention from X.

> > It either is *functionally* the same, or it isn't.
>
> You keep "shouting" that word as if saying it louder is all that's necessary.

Nope. I demonstrated how they are functionally the same with plenty of examples.

> > 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.
>
> You asked why zsh's default behavior is what it is; the answer is
> historical practice.

Indeed, and that's all that was needed to answer *that* particular question.

But then you used an historic argument to counter my claim that Zsh
was not consistent. Go look at mid [1] (I don't know how you link to
the archives, which don't seem to be updated).

This is an entirely different matter.

> Unless I've misunderstood something, the subsequent discussion has
> focused on the idea that we should change the default, despite that
> breaking several precedents, because the default behavior is not
> internally consistent, and that the reason it's not consistent is
> because of the notion that unsetting a variable is equivalent to
> assigning it an undefined value.

No. Again, go back to mid [1]. I specifically said:

"Adding a setopt option for the new behavior doesn't break a lot of
existing zsh code."

I argued it makes sense to add a setopt option that turns on the
behavior that a) in my opinion is more consistent, b) is what Bash and
ksh does, and c) is the equivalent of what virtually all languages do.

> Even if we grant the latter, which I don't think everyone does, it
> still doesn't follow that the only consistent choice for the default
> state of a declared variable is unset.

But it does follow. I already presented several arguments, most of
which have not been even addressed at all. Would like me to list them
all in a document so it's clear how they have not been addressed?

> > My understanding of [KSH_TYPESET] is that it changed the behavior of this:
> >
> >     typeset var=$(echo one word)
> >
> > To this:
> >
> >   builtin typeset var=$(echo one word)
>
> No; it changes the former to something closer to
>
>     typeset var="$(echo one word)"
>
> because *without* the option, it was interpreted as
>
> >   typeset var=one word

OK. So it's the other way around.

But this actually sets a precedent for an option that turns on
behavior similar to that of ksh, that eventually becomes the default,
because presumably it eventually made sense.

The same could happen in this case... Eventually.

Either way, I don't see any argument against adding an option (or
reusing) to turn on this behavior.

Cheers.

[1] CAH+w=7ZwyKq_RxM_RXWu42Y-RbCkRtrLTqesfqCmFNc_C_CwoA@xxxxxxxxxxxxxx

-- 
Felipe Contreras