On 28.08.2020 17:37, Oğuz wrote:
> 28 Ağustos 2020 Cuma tarihinde Greg Wooledge <wool...@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