On Tue, Apr 26, 2016 at 01:54:12PM -0400, Chet Ramey wrote:
> Thanks for the report. I will fix this before bash-4.4 is released.
Is there some way for me to work around this issue in older versions of
Bash using autocompletion hooks?
Eric
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. thi
On 30 Apr 2016, at 22:24, Grisha Levit wrote:
> 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 i
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.
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
> behavi
A number of options were not getting reset in reset_shell_flags(),
reset_shell_options() and reset_shopt_options() so scripts without #!'s
could sometimes run differently than expected.
The attached patch makes these functions more thorough and makes them
properly handle some #defines that were pr
