Re: Bug with unset variables

[Felipe Contreras <felipe.contreras@gmail.com>]

On Thu, Nov 12, 2020 at 4:48 AM Peter Stephenson
<p.w.stephenson@ntlworld.com> wrote:
>
> With some trepidation, let me see if I can try and sum up.
>
> fn() {
>    typeset foo
>    # foo is regarded as set (in the sense "not unset") here.
> }
>
> Other shells would treat foo as unset at that point.
>
> This is a long standing feature of zsh

It's not a bug, it's a feature!

Never heard that one before.

> It is a bug when emulating other shells (although note that there
> are plenty of such bugs --- emulation is never complete).  I
> said I thought we'd done something about this, but I don't see any
> evidence, so I was probably wrong.  There is definitely scope for
> improvement.

Indeed, I've been looking at the code, and there doesn't seem to be
anything similar. It's making too many assumptions about the starting
state of a parameter.

> Given that all shells would treat $foo as an empty string in
> the context above, the practical impact is limited to a few
> edge cases --- granted that can be infuriating (and more)
> when you hit one, so I am not dismissing such cases.  That's why
> this issue doesn't often come up despite its long-standing
> nature.

Absence of evidence is not evidence of absence.

Perhaps a considerable amount of people have hit this issue, but they
haven't bothered to contact the mailing lists. Most people just make
it work on their code, and move on.

> For the same reason, that $foo will reliably substitute as
> an empty string, I don't see any *overriding* reason for
> the behaviour of other shells.  That absolutely doesn't
> mean I see no arguments for that behaviour, all of
> which I think have now been rehearsed.

There is a difference between a variable that contains an empty
string, and an unset variable, this is an undeniable fact about the
shell language.

There is a reason why people use ${foo+set} instead of $foo when they
want to check if a variable is set, as opposed to empty.

The fact that most code doesn't care about the difference doesn't mean
there isn't some code that does.

Cheers.

-- 
Felipe Contreras