ok, a small correction, the problem lies in exportscope:40, but none of the patches mentioned solve it, the same behaviour of the test can be recovered with just export instead of declare on this line (at least proves that the patches dont break it ;-)). some other make_local_variable issue I guess.
pg On 5 May 2016, at 09:46, Piotr Grzybowski wrote: > > ok, so Dan wants this patch. > I took a look at your script, there are two cases it addresses: exporting > nameref and doing it from inside the function scope, I applied both patches: > > nameref masking in scope: > https://lists.gnu.org/archive/html/bug-bash/2016-05/msg00012.html > > exporting namerefs: > https://lists.gnu.org/archive/html/bug-bash/2016-05/msg00024.html > > and with this modification to your script: > > diff --git a/exportscope b/exportscope > index 05bae73..0125681 100644 > --- a/exportscope > +++ b/exportscope > @@ -37,7 +37,8 @@ function h { > ;; > 2) > typeset -n _x=$2 > - typeset -x _x='in h2' > + export -r _x; > + _x='in h2'; > eval "$showEnv" h2 > esac > } > @@ -75,4 +76,4 @@ for sh in bash ksh mksh zsh; do > printf '%s\n\n' "$("$sh" -c "$code" -- "$sh" 2>&1)" > done > > You can get (difference in test 3): > > #./exportscope > bash test 1: > subprocess f: declare -x x="in f" > local f: declare -x x="in f" > global: declare -x x="global" > bash test 2: > subprocess g: declare -x x="in g" > subprocess f: declare -x x="in f" > local f: declare -x x="in f" > local g: declare -x x="in g" > global: declare -- x="unset" > bash test 3: > subprocess h2: declare -x x="in h2" > subprocess h1: declare -x x="in h2" > local h1: declare -x x="in h2" > > Maybe you can comment on wether the patches are valid. > > cheers, > pg > > > > On 4 May 2016, at 22:40, Dan Douglas wrote: > >> Yeah I was just looking for this old script last night and just found it :) >> >> https://gist.github.com/ormaaj/04923e11e8bdc27688ad >> >> If you scroll down to the output for "test 3" where "h" gets called >> and passes a local "x" to a function that creates a reference to it >> and exports the reference you can see that bash calls "x" unset in >> both the first and second scope. As I recall we were discussing the >> way exported locals interact between scopes at the time, not namerefs, >> but I added the case for namerefs since I wasn't sure how this should >> work. I should probably run it again with the current devel branch. >> >> Even though bash doesn't yet support references for parameters like >> ksh93, neither does mksh, which also shows differences from bash. >
