Re: More rabbit-holes with unset variables

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

On Thu, Nov 26, 2020 at 12:10 AM Stephane Chazelas
<stephane@chazelas.org> wrote:

> As to unset vs initial value, both have merits. While I'd tend
> to prefer "initially unset", it makes sense that "local -i i;
> echo "$i"" outputs an integer. Or that "local -Z2 v; echo $#v"
> outputs 2.

Yes, when you are specifying a type, it's obvious what default value
you would want, and at least to me it makes sense that "typeset -a
arr" initializes $arr with an empty array. But that's not what was
discussed here.

The discussion is about what "typeset var" (with no type) should do.

> In any case, I don't think zsh can change its default behaviour
> as it would break backward compatibility.

That's what major versions are for (maybe zsh 6.0?), and backwards
compatibility has been broken before.

Anyway, in the current state of the discussion, the idea is to add the
unset behavior to "setopt ksh_typeset", so no backwards compatibility
would be broken.

> It could try and emulate ksh in ksh emulation, but which ksh?
> ksh88, ksh93 and mksh behave radically differently in that
> regard. Also few people use ksh these days, so I'm not sure it's
> worth the effort. While the ksh emulation mode can help with
> bash compatibility, bash's behaviour in this instent is also
> very different.

When no type is specified, both ksh and bash do the same thing: no
initial value is assigned.

I don't want to say "unset", since as you explained; that can entail a
lot of different behaviors depending on the shell. But rather: nil
value.

Can we agree that it makes sense that "typeset var" (with no type)
assigns $var the nil value (in other words: no value) (or at the very
least no value in the case that no global $var has been previously
set)?

Cheers.

-- 
Felipe Contreras