Re: Incorrect / Inconsistent behavior with nameref assignments in functions

[Binarus]

On 28.08.2020 17:37, Oğuz wrote:
> 28 Ağustos 2020 Cuma tarihinde Greg Wooledge <wooledg@eeg.ccf.org> yazdı:
> 
>> On Fri, Aug 28, 2020 at 10:56:34AM +0200, Binarus wrote:
>>> #!/bin/bash
>>>
>>> function Dummy() {
>>>
>>>   local -n namerefArray="$1"
>>>   local -a -i myArray=("${namerefArray[@]}")
>>>
>>>   local -p
>>> }
>>>
>>> declare -a -i myArray=('1' '2' '3')
>>
>> You've got a local variable with the same name as the global variable
>> that you're attempting to pass by reference.  This will not work.
>>
>>
> These scripts yield identical output on bash-5.1 though.

Thank you very much for testing! This is interesting. I couldn't get my
hands on a system with 5.1 yet.

With 5.1, do both scripts behave like SCRIPT 1 with the older versions
or like SCRIPT 2 with the older versions?
>> Namerefs (declare -n) in bash are *not* like uplevel commands in Tcl.
>> They cause the referenced variable name to be evaluated just like any
>> other variable would be, starting at the current function scope, then
>> going up to the caller, and so on.
>>
>> If you want to use namerefs in a function in bash, you MUST go out of
>> your way to minimize the chances of a collision between the caller's
>> variable refererance and ANY local variable of the function.  Not just
>> the nameref itself, but any other incidental variables used in the
>> function.  (As you aptly demonstrated here.)
>>
>> So, you can't write functions like this:
>>
>> func1() {
>>   declare -n ref="$1"
>>   local i
>>   ...
>> }
>>
>> Instead, you need crazy things like this:
>>
>> func1() {
>>   declare -n _func1_ref="$1"
>>   local _func1_i
>>   ...
>> }
>>
>>
> 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.

Thank you very much, and best regards,

Binarus