Path: csiph.com!goblin1!goblin.stu.neva.ru!usenet.stanford.edu!not-for-mail From: Robert Elz Newsgroups: gnu.bash.bug Subject: Re: Incorrect / Inconsistent behavior with nameref assignments in functions Date: Sat, 29 Aug 2020 01:28:13 +0700 Lines: 53 Approved: bug-bash@gnu.org Message-ID: References: <8313a366-6ecd-5e87-5552-6a4e0fe18028@binarus.de> <20200828152846.GI931@eeg.ccf.org> <5613.1598639293@jinx.noi.kre.to> NNTP-Posting-Host: lists.gnu.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: usenet.stanford.edu 1598639323 12869 209.51.188.17 (28 Aug 2020 18:28:43 GMT) X-Complaints-To: action@cs.stanford.edu Cc: bug-bash@gnu.org To: Binarus Envelope-to: bug-bash@gnu.org In-Reply-To: <8313a366-6ecd-5e87-5552-6a4e0fe18028@binarus.de> Received-SPF: permerror client-ip=2001:3c8:9009:181::2; envelope-from=kre@munnari.OZ.AU; helo=munnari.OZ.AU X-detected-operating-system: by eggs.gnu.org: No matching host in p0f cache. That's all we know. X-Spam_score_int: -14 X-Spam_score: -1.5 X-Spam_bar: - X-Spam_report: (-1.5 / 5.0 requ) BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.4, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01 autolearn=no 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: <5613.1598639293@jinx.noi.kre.to> X-Mailman-Original-References: <8313a366-6ecd-5e87-5552-6a4e0fe18028@binarus.de> <20200828152846.GI931@eeg.ccf.org> Xref: csiph.com gnu.bash.bug:16835 Date: Fri, 28 Aug 2020 18:25:23 +0200 From: Binarus Message-ID: <8313a366-6ecd-5e87-5552-6a4e0fe18028=40binarus.de> =7C > This doesn't make the slightest sense. What is the point of havin= g local =7C > variables then? =7C =7C Or namerefs ... I totally agree. Either locals or namerefs are just= =7C unusable given that situation; you have to choose between them. Not really, you just have to stop thinking like a C/python/... programmer= and think like a shell programmer instead. 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 =22eval =24var=3D'whatever'=22 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. 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) =22local=22 command copies the old value (+ attribu= utes) to somewhere unknown to the script (and inaccessible), and then when the function containing =22local=22 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 ...). So when you combine those things everything actually makes perfect sense - as long as you're expecting it to work like this, and not hoping that sh programming is just C with a different syntax. kre ps: I agree that the options given to local should make no difference, but it sounds as if whatever issue that was has already been fixed.