Path: csiph.com!goblin1!goblin.stu.neva.ru!usenet.stanford.edu!not-for-mail From: Binarus Newsgroups: gnu.bash.bug Subject: Re: Incorrect / Inconsistent behavior with nameref assignments in functions Date: Fri, 28 Aug 2020 18:25:23 +0200 Lines: 67 Approved: bug-bash@gnu.org Message-ID: References: <20200828152846.GI931@eeg.ccf.org> <8313a366-6ecd-5e87-5552-6a4e0fe18028@binarus.de> NNTP-Posting-Host: lists.gnu.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: usenet.stanford.edu 1598631930 8321 209.51.188.17 (28 Aug 2020 16:25:30 GMT) X-Complaints-To: action@cs.stanford.edu To: bug-bash@gnu.org Envelope-to: bug-bash@gnu.org X-Envelope-To: DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=binarus.de; s=b201601; t=1598631922; bh=vy7octXpAM6GU3CNrDdYjU20ldBYRWot4U3mYO94NiU=; h=Subject:To:References:From:Date:In-Reply-To:From:Reply-To:Subject: Date:To:Cc:Resent-Date:Resent-From:Resent-To:Resent-Cc:In-Reply-To: References:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; b=ECoN3R1DAm4t3TACrIaZnoBXVMlZ6I8fFMZ7WUZU/eChMT3WC8GsVeGSEXTdUZrSV TQJHVvFEGcsegbLYZ0liphwMaZxznjLqI1rJ9cOcBnCYYEoeqFkDjj7IbCysav+/OO Vg6Ui8zkeetkOiOt1VAMvdq99UBZ17xLzoaeYJDm881sOxb2iX0Cfz8VJ58hcIEJ5P bkpdtk0iuXE8DXGgn5NXEOt+YDuEHedpmz/xuh9y3YakSmSuNxQZNeffiTuExreZEl DT5SLYZ3DqxgfMC329rubq5PHYzrS5sTy1NOuUmJPb+Uloxtt8bvPmaT6L2oeAm7vq FOFsYB9cjxzXtOOI7pR/3Qe/w8yOG1NpFfyZaiwHfLUYB3xFDfph/QNIFIFoeIBenz 7RgDKtkIODFisAvHg2HEozhr/l/s9e8wWYcfCmicbMht3vPL/9UMY7MMgi8aJRRBwI x5JBebbyCw3wrldJ89qm2jJC8Sz1tTPP6L8DGzvwfeIuxFYe0LcwqLlVKFjreeKxHM Vk4VA6EtbaN2AMqmCvxUGQrHOu4tGKqdpFwSNdL8+gI6KG7JWgZCeqJ5U9VAEtXIDb GEZhjzxsk3D+aPAJ8kTfpW3ckdbal4olJOsUZi4wNuRxmvOjd8MGg5TGm4EuP6XtLx JAAnpE3ijKTVsk9v9dG2xV5s= User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 In-Reply-To: Content-Language: en-US X-Bin-MAIL-FROM: X-Bin-RCPT-TO: Received-SPF: pass client-ip=144.76.90.229; envelope-from=lists@binarus.de; helo=odysseus.binarus.de X-detected-operating-system: by eggs.gnu.org: First seen = 2020/08/28 12:20:04 X-ACL-Warn: Detected OS = Linux 2.2.x-3.x [generic] [fuzzy] X-Spam_score_int: -28 X-Spam_score: -2.9 X-Spam_bar: -- X-Spam_report: (-2.9 / 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, NICE_REPLY_A=-0.809, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: bug-bash@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Bug reports for the GNU Bourne Again SHell List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-Mailman-Original-Message-ID: <8313a366-6ecd-5e87-5552-6a4e0fe18028@binarus.de> X-Mailman-Original-References: <20200828152846.GI931@eeg.ccf.org> Xref: csiph.com gnu.bash.bug:16833 On 28.08.2020 17:37, Oğuz wrote: > 28 Ağustos 2020 Cuma tarihinde Greg Wooledge 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