Path: csiph.com!goblin2!goblin1!goblin.stu.neva.ru!usenet.stanford.edu!not-for-mail
From: =?UTF-8?B?T8SfdXo=?= <oguzismailuysal@gmail.com>
Newsgroups: gnu.bash.bug
Subject: Re: Incorrect / Inconsistent behavior with nameref assignments in functions
Date: Fri, 28 Aug 2020 23:08:31 +0300
Lines: 86
Approved: bug-bash@gnu.org
Message-ID: <mailman.1633.1598645316.2469.bug-bash@gnu.org>
References: <a20e4692-69b3-9836-4861-3e822e407ef7@binarus.de> <20200828152846.GI931@eeg.ccf.org> <CAH7i3Lpq3dWx55mGcuu4TK0gQaLCFBQwcoaeWR_-tunwxK6ijQ@mail.gmail.com> <8313a366-6ecd-5e87-5552-6a4e0fe18028@binarus.de> <CAH7i3LoPa-uepKMLMOvytgXSG9fvJed1hgV1VDGpK=kgm3vLrg@mail.gmail.com>
NNTP-Posting-Host: lists.gnu.org
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Cc: "bug-bash@gnu.org" <bug-bash@gnu.org>
To: Binarus <lists@binarus.de>
Envelope-to: bug-bash@gnu.org
In-Reply-To: <8313a366-6ecd-5e87-5552-6a4e0fe18028@binarus.de>
Received-SPF: pass client-ip=2607:f8b0:4864:20::f32; envelope-from=oguzismailuysal@gmail.com; helo=mail-qv1-xf32.google.com
X-Spam_score_int: -20
X-Spam_score: -2.1
X-Spam_bar: --
X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no
X-Spam_action: no action
X-Content-Filtered-By: Mailman/MimeDel 2.1.23
X-BeenThere: bug-bash@gnu.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Bug reports for the GNU Bourne Again SHell <bug-bash.gnu.org>
List-Unsubscribe: <https://lists.gnu.org/mailman/options/bug-bash>, <mailto:bug-bash-request@gnu.org?subject=unsubscribe>
List-Archive: <https://lists.gnu.org/archive/html/bug-bash>
List-Post: <mailto:bug-bash@gnu.org>
List-Help: <mailto:bug-bash-request@gnu.org?subject=help>
List-Subscribe: <https://lists.gnu.org/mailman/listinfo/bug-bash>, <mailto:bug-bash-request@gnu.org?subject=subscribe>
X-Mailman-Original-Message-ID: <CAH7i3LoPa-uepKMLMOvytgXSG9fvJed1hgV1VDGpK=kgm3vLrg@mail.gmail.com>
X-Mailman-Original-References: <a20e4692-69b3-9836-4861-3e822e407ef7@binarus.de> <20200828152846.GI931@eeg.ccf.org> <CAH7i3Lpq3dWx55mGcuu4TK0gQaLCFBQwcoaeWR_-tunwxK6ijQ@mail.gmail.com> <8313a366-6ecd-5e87-5552-6a4e0fe18028@binarus.de>
Xref: csiph.com gnu.bash.bug:16836

28 A=C4=9Fustos 2020 Cuma tarihinde Binarus <lists@binarus.de> yazd=C4=B1:

>
>
> On 28.08.2020 17:37, O=C4=9Fuz wrote:
> > 28 A=C4=9Fustos 2020 Cuma tarihinde Greg Wooledge <wooledg@eeg.ccf.org>
> yazd=C4=B1:
> >
> >> On Fri, Aug 28, 2020 at 10:56:34AM +0200, Binarus wrote:
> >>> #!/bin/bash
> >>>
> >>> function Dummy() {
> >>>
> >>>   local -n namerefArray=3D"$1"
> >>>   local -a -i myArray=3D("${namerefArray[@]}")
> >>>
> >>>   local -p
> >>> }
> >>>
> >>> declare -a -i myArray=3D('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.
>
>
5.1 is still in beta phase.


> With 5.1, do both scripts behave like SCRIPT 1 with the older versions
> or like SCRIPT 2 with the older versions?


They behave like SCRIPT 2 as expected, local `myArray' is populated with
the contents of global `myArray'. _identical_ was the wrong word though,
the second script doesn't copy the integer attribute.


> >> 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=3D"$1"
> >>   local i
> >>   ...
> >> }
> >>
> >> Instead, you need crazy things like this:
> >>
> >> func1() {
> >>   declare -n _func1_ref=3D"$1"
> >>   local _func1_i
> >>   ...
> >> }
> >>
> >>
> > This doesn't make the slightest sense. What is the point of having loca=
l
> > 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
>
>

--=20
O=C4=9Fuz