Re: about the local not-on-every-function-separately var issue
On 3/22/21 9:38 PM, Dale R. Worley wrote: In my experience, a common reason is that the documentation does not concentrate in one place that users are certain to read, a complete, clear description of the situation. For instance, you give a complete, clear description: Bash uses "dynamic scope" when it expands variables. This means that it looks first in the current functions local variables; if the variable isn't found there, it looks in the caller's local variables, and then in the caller's caller's local variables, and so on, until it reaches the global scope. Well, there is this in the FUNCTIONS section of the man page: "The shell uses dynamic scoping to control a variable's visibility within functions. With dynamic scoping, visible variables and their values are a result of the sequence of function calls that caused exe- cution to reach the current function. The value of a variable that a function sees depends on its value within its caller, if any, whether that caller is the "global" scope or another shell function. This is also the value that a local variable declaration "shadows", and the value that is restored when the function returns. For example, if a variable var is declared as local in function func1, and func1 calls another function func2, references to var made from within func2 will resolve to the local variable var from func1, shadow- ing any global variable named var." -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: about the local not-on-every-function-separately var issue
On 3/22/21 9:38 PM, Dale R. Worley wrote: > Greg Wooledge writes: >> Now, the big question is WHY you thought something which is not correct. >> >> The most common reasons that people think something which is wrong are: > > In my experience, a common reason is that the documentation does not > concentrate in one place that users are certain to read, a complete, > clear description of the situation. For instance, you give a complete, > clear description: > > Bash uses "dynamic scope" when it expands variables. This means that > it looks first in the current functions local variables; if the variable > isn't found there, it looks in the caller's local variables, and then > in the caller's caller's local variables, and so on, until it reaches > the global scope. > > And that behavior is implied if you read the definition of "local" > closely. But I couldn't find any text in the manual page that states > that directly. It's described pretty plainly in FUNCTIONS. It even mentions dynamic scoping as an explicit term. "Ordinarily, variables and their values are shared between the function and its caller. If a variable is declared local, the variable's visible scope is restricted to that function and its children" It also finishes off its description by pointing out "When the function returns, the global variable is once again visible." > (*Very* closely, as the text refers to "the function and > its children". But function definitions don't nest; what it means is > "the function *invocation* and its child invocations.) Since you yourself felt the need to describe this as "nested" functions, not "child" functions, I'm curious why you thought nested functions as a source code paradigm is a better comparison than, say, parent/child processes as an invocation paradigm? python has nested functions. If I ever heard someone refer to a child function in python, I would not expect it to refer to nested functions -- I'd expect it to refer to the call stack. Going back to the previous definition I pointed out... note the explicit comparison of "caller" and "children" as opposites. > In principle it > should be stated at the point where parameter expansion is introduced, > as it is the *definition* of what parameter expansion does. I don't see what principle makes you think it should be removed from its current location, the description of functions (which is extremely relevant to function scoping) and moved to parameter expansion, which is currently all about the syntax rules non-local and local variables share. Which is still not the location where local is defined and described. -- Eli Schwartz Arch Linux Bug Wrangler and Trusted User OpenPGP_signature Description: OpenPGP digital signature
Re: about the local not-on-every-function-separately var issue
Greg Wooledge writes: > Now, the big question is WHY you thought something which is not correct. > > The most common reasons that people think something which is wrong are: In my experience, a common reason is that the documentation does not concentrate in one place that users are certain to read, a complete, clear description of the situation. For instance, you give a complete, clear description: Bash uses "dynamic scope" when it expands variables. This means that it looks first in the current functions local variables; if the variable isn't found there, it looks in the caller's local variables, and then in the caller's caller's local variables, and so on, until it reaches the global scope. And that behavior is implied if you read the definition of "local" closely. But I couldn't find any text in the manual page that states that directly. (*Very* closely, as the text refers to "the function and its children". But function definitions don't nest; what it means is "the function *invocation* and its child invocations.) In principle it should be stated at the point where parameter expansion is introduced, as it is the *definition* of what parameter expansion does. Dale
Re: about the local not-on-every-function-separately var issue
im sorry to not be able to reply to all your stuffs
you didnt make it easy
im happy it works for me now
On Mon, Mar 22, 2021 at 3:43 AM Greg Wooledge wrote:
>
> On Mon, Mar 22, 2021 at 03:12:25AM +0100, Alex fxmbsw7 Ratchev wrote:
> > i realize its somewhat of a big limitation, to have only global and
> > one level further ( local ) args, no per function
>
> One or more of your assumptions are wrong.
>
> Bash uses "dynamic scope" when it expands variables. This means that
> it looks first in the current functions local variables; if the variable
> isn't found there, it looks in the caller's local variables, and then
> in the caller's caller's local variables, and so on, until it reaches
> the global scope.
>
>
> f() {
> local var=set_in_f
> g
> }
>
> g() {
> echo "var is $var"
> }
>
> var=global
> f
> # Prints "var is set_in_f"
>
>
> Now, the big question is WHY you thought something which is not correct.
>
> The most common reasons that people think something which is wrong are:
>
> 1) They heard or read it somewhere, and did not verify it themselves.
>
> 2) They encountered a problem with their own program, and while attempting
>to track down the problem, they took a wrong turn, and did not fully
>diagnose the situation. They drew a wrong conclusion from partial data.
>
> In your case, I suspect it's #2.
>
> This project that you've been working on is so incredibly arcane,
> convoluted and bizarre that *nobody* understands it, including you. Who
> knows how many other fallacious assumptions are baked into it, since you
> are apparently incapable of simplifying anything down to the most basic
> level for debugging, or even explaining what your *goal* is.
>
Re: about the local not-on-every-function-separately var issue
Date:Sun, 21 Mar 2021 22:42:19 -0400 From:Greg Wooledge Message-ID: | One or more of your assumptions are wrong. | | Bash uses "dynamic scope" when it expands variables. Note that some other shells don't really have local variables at all, there are only globals - the "local" command saves a copy of the state of the variable at that point, and arranges to restore it when the current function exits. Lookups of variables only ever look in the global variable list. This is a much simpler model to understand, otherwise it is hard to see how things like "local PATH IFS OPTARG" (etc) can ever really work (variables used or set by the shell itself). | Now, the big question is WHY you thought something which is not correct. | | The most common reasons A third is that they know some other environment, and then expect everything to be just the same as that one, and that things should always behave the way they're familiar with.That's not the way the world works. Different things are different (even different shells and how they treat "local", which is one reason, maybe "the" reason, why "local" isn't in the POSIX shell standard). I totally agree with the part about convoluted code however, I have never been able to understand anything of what is being attempted. kre
Re: about the local not-on-every-function-separately var issue
On Mon, Mar 22, 2021 at 03:12:25AM +0100, Alex fxmbsw7 Ratchev wrote:
> i realize its somewhat of a big limitation, to have only global and
> one level further ( local ) args, no per function
One or more of your assumptions are wrong.
Bash uses "dynamic scope" when it expands variables. This means that
it looks first in the current functions local variables; if the variable
isn't found there, it looks in the caller's local variables, and then
in the caller's caller's local variables, and so on, until it reaches
the global scope.
f() {
local var=set_in_f
g
}
g() {
echo "var is $var"
}
var=global
f
# Prints "var is set_in_f"
Now, the big question is WHY you thought something which is not correct.
The most common reasons that people think something which is wrong are:
1) They heard or read it somewhere, and did not verify it themselves.
2) They encountered a problem with their own program, and while attempting
to track down the problem, they took a wrong turn, and did not fully
diagnose the situation. They drew a wrong conclusion from partial data.
In your case, I suspect it's #2.
This project that you've been working on is so incredibly arcane,
convoluted and bizarre that *nobody* understands it, including you. Who
knows how many other fallacious assumptions are baked into it, since you
are apparently incapable of simplifying anything down to the most basic
level for debugging, or even explaining what your *goal* is.
about the local not-on-every-function-separately var issue
i realize its somewhat of a big limitation, to have only global and
one level further ( local ) args, no per function
however about my code, i fixed it with a growing mapfile reader
'mapfile -t -d "" -O ${#big[@]} big <"$_hd"/init/"$per"' \
or at least partly fixed, yet stuff worked
and eval that in the end
i think the for loop didnt change anything as that wasnt a copy-var also
i wonder what a solultion to this would be
