On 3/22/21 9:38 PM, Dale R. Worley wrote: > Greg Wooledge <g...@wooledge.org> 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