Re: issues with nameref resolution loop in a function
On 12/8/18 8:30 PM, Grisha Levit wrote: > There seems to be an issue with the following new bash-5.0 feature: > > A nameref name resolution loop in a function now resolves to a variable by > that name in the global scope. > > [ Note: "warning: x: circular name reference" messages omitted below. ] > > While referencing such a nameref works as described, scalar assignment to it > modifies the variable from the next higher scope rather than the global one: Yes, that's what it does right now. The resolution change is the only one I made, and I'm still not convinced it's the right thing. The code that does the assignment is unchanged, with a comment that says backwards compatibility. That code can operate on the global instance, ignore the nameref attribute and change the value, or just ignore the variable as if it didn't exist. Right now it does what it did in bash-4.4. (Cue Greg and his "nameref variables are an unworkable botch and should just be ignored.") -- ``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: temp env allows variables that look like array subscripts
On 12/8/18 11:45 PM, Grisha Levit wrote: > FWIW, namerefs in the temporary environment bypass the implemented checks: > > $ declare -n ref=var[0] > $ ref=X printenv 'var[0]' > X Thanks for the report. We should follow namerefs, but in this case not allow nameref values that aren't valid shell identifiers. I will fix this for the next devel branch push. -- ``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: assignment to a nameref that resolves to the temporary environment
On 12/9/18 1:28 AM, Grisha Levit wrote:
> When a nameref local to a higher function scope points to a variable in the
> temporary environment, that nameref (correctly, it seems) expands to the
> value
> of the target variable from the temporary environment. However, assignment
> to
> the nameref modifies the variable from the higher scope, bypassing the
> tempenv:
>
> $ a() { local -n ref=var; var=tmp b; echo $ref; }
> $ b() { ref=$ref; }
> $ var=foo; a
> tmp
Here's what happens when you execute `b'. The variable `var' is put into
the temporary environment with value `tmp'. The resolution for $ref looks
at the current environment, finds nothing, looks at the previous
environment (a), and finds a nameref with value `var'. It *restarts* the
lookup to resolve `var', finds it in the temporary environment, and expands
to `tmp'. So that's the value, and the assignment becomes `ref=tmp'.
The assignment code goes looking for `ref' and finds it in the previous
context as a nameref with value `var'. This is where the asymmetry occurs.
When performing an assignment, the shell starts at the context where the
nameref is found, rather than starting at the original context -- which in
this case, would have found the variable in b's temporary environment.
Do you think it's reasonable to have this restriction, given the nature of
bash's dynamic variable scoping, or should it restart the lookup from the
original variable context? You can get yourself into some pretty nasty
nameref loops if you go back to the original context.
Chet
--
``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/
