[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: a nameref may resolve to different variables in assignment and param

From: Chet Ramey
Subject: Re: a nameref may resolve to different variables in assignment and parameter expansion
Date: Fri, 7 Jan 2022 10:23:30 -0500
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.4.1

On 1/6/22 1:31 PM, Mark March wrote:
It appears that the same initialized nameref variable may refer to variables in 
different scopes depending on the context where it is used. When used in an 
assignment, a nameref will look for the variable it references starting at the 
scope where the nameref itself was found, which may be below the current scope. 
In a parameter substitution a nameref will always start looking for its target 
in the current scope.

Yes, that's true. It's consistent with the model of a nameref as a symlink
for variable names. What happens is what you suspect: for an assignment,
the resolution process looks up the variable name starting in the current
scope and going back to previous scopes, then, if the name is found,
continues the lookup with the new name instead of starting over.

There's a comment in the code (variables.c:bind_variable()) detailing
exactly where to change it if you want to experiment.

On a side note, my personal preference would be to have namerefs remember the scope of the variable that they reference (once that scope is known), and always resolve to that same SHELL_VAR, until unset, instead of looking up a SHELL_VAR by name, as is the current behavior.

That would turn dynamic scoping into essentially static scoping, and I'm
not ready to go there yet.

``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet@case.edu    http://tiswww.cwru.edu/~chet/

reply via email to

[Prev in Thread] Current Thread [Next in Thread]