Re: declare [-+]n behavior on existing (chained) namerefs

[Grisha Levit]

> interpret "on the variable" as doing a depth first search (going as deep as possible over the reference chain) in order to find the variable

Yes, that makes perfect sense, but I think all the issues above don't concern the search for the variable, but rather modifications to the references themselves.

This might just be a documentation issue, as the docs state that something different should be happening:

1. It seems unambiguous from the description that `declare +n ref_1' should remove the nameref attribute from ref_1, not from any other variable

2. A strict interpretation would also suggest that `declare -n ref_1=foo' should change the value of the variable referenced by the nameref (or the chain of references), not the value of ref_N.  I don't know if that's really the implementation's intention -- perhaps adding a note to the "If a variable name is followed by =value, the value of the variable ..." section of the declare builtin's description would help clarify this case.

On Wed, Apr 27, 2016 at 5:54 PM, Piotr Grzybowski <narsil.pl@gmail.com> wrote:

 this one does not seem like a bug to me, rather a decision made by the author: to interpret "on the variable" from this:

"All references, assignments, and attribute modifications to name, except for changing the -n attribute itself, are performed on the variable referenced by name’s value."

as doing a depth first search (going as deep as possible over the reference chain) in order to find the variable. The last case you mention is discussable: when the leaf is an empty reference should +n do something? Probably should do the same as declare +n ref_N; which I think is just to leave a variable with identifier ref_N. But then, ref_((N-1)) points to a variable and suddenly there is a potentially unexpected change in your lovely tree of empty references.
 One can argue: if you pass the ref_i to some function, and you want to modify ref_N how to do it? The choice made seems fairy logical, I am not saying that it is the best possible one though.

cheers,
pg

On 27 Apr 2016, at 21:26, Grisha Levit wrote:

> declare -n name=value, when name is already a nameref, shows the following presumably inconsistent behavior:
>
> Given a chain of namerefs like:
>
> ref_1 -> ref_2 -> ... -> ref_i ... -> ref_N [-> var]
>
>       • If ref_N points to a name that is not a nameref, the operations declare -n ref_N=value and declare +n ref_N modify the value/attributes of ref_N (this seems to be the desired behavior)
>       • For i<N, declare -n ref_i=value and declare +n ref_i modify the value/attributes of ref_N and not of ref_i
>       • If ref_N is declared as a nameref but unset, then these operations on ref_i have no effect.
> For example, starting with:
>
> unset -n ref{1..3
> }
>
> declare
>  -n ref1=ref2 ref2=ref3 ref3=var1
>
> # declare -n ref1=var2
> # declare -p ref{1..4}
> declare -n ref1="ref2"   # unchanged
> declare -n ref2="ref3"
> declare -n ref3="var2"   # changed
> # declare +n ref1
> # declare -p ref{1..3}
> declare -n ref1="ref2"   # unchanged
> declare -n ref2="ref3"
> declare -- ref3="var1"   # changed, no loner nameref
> Or alternatively:
>
> unset -n ref{1..3
> }
>
> declare
>  -n ref1=ref2 ref2=ref3 ref3
>
> # declare +n ref1
> # declare -p ref{1..3}
> declare -n ref1="ref2"   # unchanged
> declare -n ref2="ref3"   # unchanged
> declare -n ref3          # unchanged
> # declare -n ref1=var1
> # declare -p ref{1..3}
> declare -n ref1="ref2"
> declare -n ref2="ref3"
> declare
>  -n ref3
>
> The man page says:
>
> All references, assignments, and attribute modifications to name, except for changing the -n attribute itself, are performed on the variable referenced by name’s value.
>
> This does not appear to be the case, as declare -n ref_N=value changes $ref_N, not $value, and declare +n ref_i changes ref_N.
>