Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > gnu.bash.bug > #16835

Re: Incorrect / Inconsistent behavior with nameref assignments in functions

Path csiph.com!goblin1!goblin.stu.neva.ru!usenet.stanford.edu!not-for-mail
From Robert Elz <kre@munnari.OZ.AU>
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 <mailman.1628.1598639322.2469.bug-bash@gnu.org> (permalink)
References <8313a366-6ecd-5e87-5552-6a4e0fe18028@binarus.de> <a20e4692-69b3-9836-4861-3e822e407ef7@binarus.de> <20200828152846.GI931@eeg.ccf.org> <CAH7i3Lpq3dWx55mGcuu4TK0gQaLCFBQwcoaeWR_-tunwxK6ijQ@mail.gmail.com> <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 <lists@binarus.de>
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 <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 <5613.1598639293@jinx.noi.kre.to>
X-Mailman-Original-References <8313a366-6ecd-5e87-5552-6a4e0fe18028@binarus.de> <a20e4692-69b3-9836-4861-3e822e407ef7@binarus.de> <20200828152846.GI931@eeg.ccf.org> <CAH7i3Lpq3dWx55mGcuu4TK0gQaLCFBQwcoaeWR_-tunwxK6ijQ@mail.gmail.com>
Xref csiph.com gnu.bash.bug:16835

Show key headers only | View raw


    Date:        Fri, 28 Aug 2020 18:25:23 +0200
    From:        Binarus <lists@binarus.de>
    Message-ID:  <8313a366-6ecd-5e87-5552-6a4e0fe18028@binarus.de>


  | > 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.

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 "eval $var='whatever'" 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) "local" command copies the old value (+ attribuutes)
to somewhere unknown to the script (and inaccessible), and then when
the function containing "local" 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.



Back to gnu.bash.bug | Previous | Next | Find similar


Thread

Re: Incorrect / Inconsistent behavior with nameref assignments in functions Robert Elz <kre@munnari.OZ.AU> - 2020-08-29 01:28 +0700

csiph-web