Re: Incorrect / Inconsistent behavior with nameref assignments in functions

[Binarus]

At first, thank you very much for your effort and the understandable
explanation.

On 28.08.2020 20:28, Robert Elz wrote:
>     Date:        Fri, 28 Aug 2020 18:25:23 +0200
>     From:        Binarus <lists@binarus.de>
>     Message-ID:  <8313a366-6ecd-5e87-5552-6a4e0fe18028@binarus.de>
> 
> 
>   | > This doesn't make the slightest sense. What is the point of having local
>   | > variables then?
>   |
>   | Or namerefs ... I totally agree. Either locals or namerefs are just
>   | unusable given that situation; you have to choose between them.

> namerefs (as I understand them, I don't write bash scripts) provide
> a way to make use of a variable name that can vary, without needing
> to resort to "eval $var='whatever'" type tricks.   But aside from being
> easier to use, that's essentially what they do, the nameref variable
> is simply replaced by its value, and used as if that was typed.

One of my problems was that my two scripts behave differently in current
release version of bash. It may be questionable which behavior would be
the correct one, but at least the two scripts should behave the same.
Otherwise, it's a bug.

> locals (in general, bash's model is slightly different in some details)
> are not new variables really (they're not like a local variable in
> C or whatever) - instead the best way to think of a local variable is
> that the (executable) "local" command copies the old value (+ attribuutes)
> to somewhere unknown to the script (and inaccessible), and then when
> the function containing "local" returns, those values and attributes
> are copied back again (by default bash also unsets local vars initially,
> other shells don't, they simply retain whatever value they had previously).
> That is, there really is just one variable of each name, and it is global
> (other functions that you call access your local variable when they refer
> to it by name, not a global they would get if the func with the local
> statement was not active ...).

This explanation is very good and understandable - thank you very much!
But unfortunately, it makes clear even more that namerefs are nearly
useless in current release versions of bash.

I am very grateful that the bash folks obviously have recognized and
solved that problem in 5.1, and obviously have partially dumped the
policy you have described above. I really hope that this has not
happened accidentally, but by intention.

It will be very interesting whether the man page for 5.1 differs from
that for the previous versions in this respect. I'll eventually try to
get my hands on the manual for 5.1 and find out about it.

Thanks again, and best regards,

Binarus