Zsh Mailing List Archive
Messages sorted by: Reverse Date, Date, Thread, Author

Re: The emulation rabbit-hole RE typeset/unset



On Fri, Nov 27, 2020 at 6:37 PM Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> wrote:
>
> On Fri, Nov 27, 2020 at 4:00 PM Felipe Contreras
> <felipe.contreras@xxxxxxxxx> wrote:
> >
> > This is a bit tautological, because if the variable is unset, it can't
> > be anything else but a string: param_is_unset(p) ->
> > param_type_is_string(p).
>
> This is manifestly not true in ksh and bash, because:
>
> [[ ${foo-nil} = nil ]] implies foo is unset
> { typeset -i foo } declares foo is an integer, not a string
> function ff { typeset -i foo; echo ${foo-nil}; } outputs nil

All right, that is true.

But then, if we have this:

  typeset -i foo

At this point "foo" is unset (in bash and ksh). It does not have a
value, and ${foo-nil} is nil. So for all intents and purposes it is
nil.

Then, we decide to add 1 to it:

  ((foo += 1))

The result is 1 (in bash and ksh).

This is interesting.

Irrespective of the fact that foo is unset, you can still add 1 to it,
so in bash and ksh it doesn't matter that foo initially is *not* 0;
you can still add to it.

So this:

  f() { ((foo +=1 )); echo ${foo-nil}; }

Returns the same in all shells: 1. You don't need to define "foo" first.

So the statement 'the only useful "declared but not set" variable is a
simple scalar' does not seem to be true.

An integer is not a "simple scalar", and seems to be useful unset.

Or am I missing something?

Cheers.

-- 
Felipe Contreras




Messages sorted by: Reverse Date, Date, Thread, Author