Stephane Chazelas via austin-group-l at The Open Group wrote in
<gahz3sr63yjjipnnqihxcrii62bh553sropphtyswu3bvjhbj3@rtvdm7322dpa>:
|2024-11-02 05:55:52 +0000, Andrew via austin-group-l at The Open Group:
|> I see oft repeated that shells presently use the keyword
|> `local` with varying semantics, as if anyone needed to be
|> constantly reminded of this trivial fact.
|
|For reference, see
|https://unix.stackexchange.com/questions/493729/list-of-shells-that-supp\
|ort-local-keyword-for-defining-local-variables/493743#493743
|for an attempt at giving a state of the art in that regard.
...
|What do you think?
Quite some years ago i proposed perl's "my" on this list.
Later "our". And i think i said that new keywords avoid
ambiguities. (Shells could simply alias the one or the other.)
As another context.
For the MUA i maintain i implemented "local" as "my", as well as
"our" as what eg bash has for "local".
But because of what follows belows and is possibly not interesting
for you i personally would refrain from proposing anything else
but this "our" style "local" for the shell, even though it is
surely easier for the shell than for my MUA (assuming
"environment" is nothing but a bit).
I say Ciao! already here.
However, with the new release we then also have many more
options like being able to use this prefix for functions etc to
localize any (and later meaning more than variable settings
even) changes deeper in the call chain:
Up to three different scopes may apply to a command invocation, each ei‐
ther local†, our† or global†: pp† for positional parameter processing
(and during eval†uation), >† for result storage, and finally for the com‐
mand and its side-effects as such; commands with the sole purpose of cre‐
ating result storage, like read† or readall†, may have no >†, but only
command-scope. “Scope” may mean different things, please see our†.
The following, most complicated possible example accesses the global† po‐
sitional parameter stack via vpospar†, stores the result in our† variable
‘i2’, and creates a local† temporary variable during argument option pro‐
cessing:
define hi {
local pp our >i$((i = 1 + 1)) global vpospar quote
xcall t "$@"
}
It must however be said that "local" documents
Remarks: whereas localized free-form user INTERNAL VARIABLES†
are only visible within the macro (define†, account†) in which
they are declared, and “shadow” all other names, for
ENVIRONMENT† and Built-in variables† local† effectively equals
our†.
And this is why i refrain from my "my" shouting many years ago,
and even have this comment for this next release:
*@ FIXME . Drop our way of `local' and `our'.
*@ FIXME Instead only support `local' AS `our', like the sh(1)ell does.
*@ FIXME This gets rid of special handling of built-ins etc for `local'.
*@ FIXME We then need `our' only for `call' and `xcall', it seems better
*@ FIXME to add two commands call_embed and call_if_embed, drop modifier.
Ie i regret ever having introduced local and our the way i did.
(And no automatic tail call optimization: most shells are
smarter.)
--steffen
|
|Der Kragenbaer, The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
|
|And in Fall, feel "The Dropbear Bard"s ball(s).
|
|The banded bear
|without a care,
|Banged on himself fore'er and e'er
|
|Farewell, dear collar bear
