Re: Global variable modification by nameref chain

On 6/14/16 12:16 PM, Dan Douglas wrote: > On Sun, Jun 12, 2016 at 8:33 PM, Chet Ramey wrote: >> 3. Honor the assignment and delete the nameref variable, creating a new >>one, like bash-4.3: >> >> $ ../bash-4.3-patched/bash ./x1 >> declare -n a="b" >> declare -n b="a[1]" >> declare -a a='([1]="

Re: Global variable modification by nameref chain

On Sun, Jun 12, 2016 at 8:33 PM, Chet Ramey wrote: > 3. Honor the assignment and delete the nameref variable, creating a new >one, like bash-4.3: > > $ ../bash-4.3-patched/bash ./x1 > declare -n a="b" > declare -n b="a[1]" > declare -a a='([1]="foo")' > declare -n b="a[1]" I kind of like this

Re: Global variable modification by nameref chain

On 6/9/16 6:06 AM, Dan Douglas wrote: > $ bash -c 'typeset -n a=b b; b=a[1]; a=foo; typeset -p a b' # bash 4.3 > declare -a a='([1]="foo")' > declare -n b="a[1]" > $ ./bash -c 'typeset -n a=b b; b=a[1]; typeset -p a b; a=foo' # 4.4 > declare -n a="b" > declare -n b="a[1]" > ./bash: line 0: `a[1]

Re: Global variable modification by nameref chain

On Thu, Jun 9, 2016 at 4:34 AM, Dan Douglas wrote: > How about just doing it similar to the way mksh resolves arithmetic > variable loops? As each variable is visited, add it to a list (or hash > set) and check whether that node was already visited. That should work > without having to consider sc

Re: Global variable modification by nameref chain

How about just doing it similar to the way mksh resolves arithmetic variable loops? As each variable is visited, add it to a list (or hash set) and check whether that node was already visited. That should work without having to consider scope issues. $ mksh -c 'a=b b=c c=d d=1; echo $((a))' 1 $ mk

Re: Global variable modification by nameref chain

On Sat, Jun 4, 2016 at 5:48 PM, Grisha Levit wrote: > On May 23, 2016 1:42 PM, "Chet Ramey" wrote: >> > Should the assignment work? I'm considering changing the >> > assignments to >> > work more like the references. >> > >> > I think it would be useful for the assignment to work, as tha

Re: Global variable modification by nameref chain

On May 23, 2016 1:42 PM, "Chet Ramey" wrote: > > Should the assignment work? I'm considering changing the assignments to > > work more like the references. > > > > I think it would be useful for the assignment to work, as that allows > > functions to take variable names as arguments witho

Re: Global variable modification by nameref chain

On 5/23/16 11:32 AM, Grisha Levit wrote: > > On Sun, May 22, 2016 at 10:08 PM, Chet Ramey > wrote: > > Should the assignment work? I'm considering changing the assignments to > work more like the references. > > > I think it would be useful for the assignme

Re: Global variable modification by nameref chain

On Sun, May 22, 2016 at 10:08 PM, Chet Ramey wrote: > Should the assignment work? I'm considering changing the assignments to > work more like the references. > I think it would be useful for the assignment to work, as that allows functions to take variable names as arguments without worrying a

Re: Global variable modification by nameref chain

On 5/22/16 6:06 PM, Grisha Levit wrote: > The expansion part really seems like the bug here, and can be demonstrated > without any crazy cross-scope chains. > > As I understand it, the intention is indeed to allow namerefs to point to > outer-scope variables, even if they happen to have the same

Re: Global variable modification by nameref chain

The nameref resolution search doesn’t re-start back at the original context. It’s like a symbolic link — it continues at the same context as the resolved nameref. If the assignment to the global variable is intentional, then shouldn’t expansion use the global variable’s value as well? The expansi

Re: Global variable modification by nameref chain

On Fri, May 6, 2016 at 8:28 AM, Grisha Levit wrote: > The issue I was trying to raise is that assignment modifies the global > variable but expansion uses the local value. > If the assignment to the global variable is intentional, then shouldn't > expansion use the global variable's value as well?

Re: Global variable modification by nameref chain

The issue I was trying to raise is that assignment modifies the global variable but expansion uses the local value. If the assignment to the global variable is intentional, then shouldn't expansion use the global variable's value as well?

Re: Global variable modification by nameref chain

On 4/27/16 9:05 AM, Grisha Levit wrote: > Is the behavior below expected? In the presence of a local $var, the > /global/ $var can be modified by assigning a value to a local nameref that > points to a global nameref that points to $var. However, the local nameref > expands to the /local/ value of