[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: a nameref may resolve to different variables in assignment and param
Re: a nameref may resolve to different variables in assignment and parameter expansion
Fri, 7 Jan 2022 10:23:30 -0500
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 firstname.lastname@example.org http://tiswww.cwru.edu/~chet/