On 8/12/16 11:30 AM, Andreas Kusalananda Kähäri wrote:
> My workaround is currently to slightly obfuscate the name of the local
> nameref previously called "var" in each function so that their names
> won't clash within the library and so that it's less likely that they
> clash with global variabl
On Fri, Aug 12, 2016 at 09:34:40AM -0400, Chet Ramey wrote:
> On 8/10/16 12:06 PM, Andreas Kusalananda Kähäri wrote:
>
> > Bash Version: 4.3
> > Patch Level: 46
> > Release Status: release
> >
> > Description:
> > When declaring a variable in a function as a nameref, it can not
> > be der
On 8/10/16 12:06 PM, Andreas Kusalananda Kähäri wrote:
> Bash Version: 4.3
> Patch Level: 46
> Release Status: release
>
> Description:
> When declaring a variable in a function as a nameref, it can not
> be dereferenced if the variable it's a nameref to happen to have
> the same name
On 8/11/16 5:10 PM, Piotr Grzybowski wrote:
> I personally believe that we should make this change (of course not before
> 4.4 ;-)), and that it should follow the global nameref chain.
> The patch (not breaking the test suite) follows.
The problem with this fix, and part of what makes the situ
Hi,
amending the previous approach; please find the attached patch: the global
namerefs are followed, and resolved in the function scope. It works as follows:
bash-4.4$ typeset -n v=w; typeset -n w=x; typeset -n x=v; x=4
bash: warning: x: circular name reference.
bash-4.4$ declare -n ref="HOME
Hi,
since we already allow circular refs in the variable_context, the below
answers your request. It means: in the function scope the name references to
existing global variables will be correctly resolved. Please note that using
find_global_variable in global_variable=find_global_variable(new
