Re: [BUG & tentative PATCH] Invalid call to upscope in createparam

[Philippe Altherr <philippe.altherr@xxxxxxxxx>]

Before you run off and write a treatise on your objections to or any
further implementation inconsistencies you've found with this, because
I know there are some, please allow me to finish reconstructing some
of the basis here.  I may be able to resolve the question to
everyone's satisfaction without subjecting the rest of the list to
another lengthy dispute.

A good start would be to state what exactly an assignment to a reference that refers to a not-yet-defined variable is supposed to do. Nothing? Create a variable? In which scope?

I'm truly flabbergasted that creating a global variable is NOT the answer, since that's what the implementation does, what ksh does, and what I inferred from the documentation.

Philippe

On Tue, Jun 3, 2025 at 12:04 AM Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> wrote:

On Mon, Jun 2, 2025 at 2:53 PM Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> wrote:
>
> Yes, I think that's actually an inconsistency introduced somewhere
> along the way.  At some point it became the case that (where var1 and
> var2 do not exist):
>   typeset -n ref1=var1 # sets base to global scope
>   typeset -n ref2 # sets base to locallevel
>   ref2=var2 # does not change base
> I think the first was meant to work like the second, not that the
> second was meant to work like the first.  None of the tests except
> foo=zz tries that ref1=var1 case where var1 hasn't already been
> declared.

Before you run off and write a treatise on your objections to or any
further implementation inconsistencies you've found with this, because
I know there are some, please allow me to finish reconstructing some
of the basis here.  I may be able to resolve the question to
everyone's satisfaction without subjecting the rest of the list to
another lengthy dispute.