Date: Fri, 28 Aug 2020 18:25:23 +0200
From: Binarus <li...@binarus.de>
Message-ID: <8313a366-6ecd-5e87-5552-6a4e0fe18...@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.
