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

On 26 May 2016, at 21:03, Chet Ramey wrote: > On 4/27/16 3:26 PM, Grisha Levit wrote: >> |declare -n name=value|, when |name| is already a nameref, shows the >> following presumably inconsistent behavior: > > There's a fairly compelling argument -- and I think Piotr made it -- that > `declare

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

On 4/27/16 3:26 PM, Grisha Levit wrote: > |declare -n name=value|, when |name| is already a nameref, shows the > following presumably inconsistent behavior: There's a fairly compelling argument -- and I think Piotr made it -- that `declare -n' shouldn't follow the nameref chain at all. If it

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

On 13 May 2016, at 23:31, Grisha Levit wrote: > All the behavior inside functions now seems consistent with what is in the > docs. But the behavior at global scope still seems strange (sorry if this is > still a WIP): > Each of the following produces different results in global scope and inside

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

On Thu, May 5, 2016 at 2:22 PM, Chet Ramey wrote: > The only buggy behavior when inside of functions (ignoring scope issues) > > seems to be that `declare -n ref’ unsets the value of $ref if it > previously > > pointed to a variable that is unset. > > I fixed this as part of

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

On 4/28/16 9:49 PM, Grisha Levit wrote: > In a slightly different version, with `declare -n r; r=a', the function > exits with code 1 after the `r=a' statement: > > $ declare -nt r=a; f() { declare a; declare -n r; r=a; declare -p a r; }; > f; echo $? > 1 In this case, you create a

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

On 5/2/16 1:55 PM, Piotr Grzybowski wrote: > Hi, > > I hope the attached patch does not break to much; it addresses the masking: > >> declare -nt r=a; f() { declare a; declare -n r=a; declare -p a r; }; f > > as per Grisha's report; it tries to enlighten make_local_variable to the > existence

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

On 4/29/16 12:50 PM, Grisha Levit wrote: > The only buggy behavior when inside of functions (ignoring scope issues) > seems to be that `declare -n ref’ unsets the value of $ref if it previously > pointed to a variable that is unset. > > |$ f() { unset var; declare -n ref=var; declare -n ref;

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

Hi, I hope the attached patch does not break to much; it addresses the masking: > declare -nt r=a; f() { declare a; declare -n r=a; declare -p a r; }; f as per Grisha's report; it tries to enlighten make_local_variable to the existence of nameref by returning existing local nameref in scope

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

after discussion with Grisha, the reason to different behaviour between: f() { declare -n ref=var; declare -n ref; declare -p ref; }; f and f() { local var; declare -n ref=var; declare -n ref; declare -p ref; }; f is: in function context declare built-in always calls make_local_variable.

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

I just re-built bash-20160415 snapshot and am observing the same behavior. To clarify, the first case is the unexpected one -- shouldn't `declare -n ref=var; declare -n ref' be a no-op, no matter if $var is set or not? It is a no-op when in global scope, but not inside a function.

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

hi, this one is not present in current devel, I would consider it fixed already. pg On 29 Apr 2016, at 18:50, Grisha Levit wrote: > I should note also that the behavior when inside a function matches exactly > what the manual says. It’s the global namerefs that have this unexpected >

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

I should note also that the behavior when inside a function matches exactly what the manual says. It’s the global namerefs that have this unexpected behavior of following the chain to the end and and modifying only the last nameref in the chain. The only buggy behavior when inside of functions

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

On 29 Apr 2016, at 03:49, Grisha Levit wrote: > There is also an issue when doing something like `declare -n r=a' in a > function if the same has been done in a higher scope. Instead of creating a > new variable r in the function's scope, it modifies the local `a' to be a > self-referencing

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

There is also an issue when doing something like `declare -n r=a' in a function if the same has been done in a higher scope. Instead of creating a new variable r in the function's scope, it modifies the local `a' to be a self-referencing nameref.. $ declare -nt r=a; f() { declare a; declare -n

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

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."

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

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