[PATCH 1/1] Properly reset options for run of #!-less script
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 previously not being respected. --grisha 0001-Properly-reset-options-for-run-of-less-script.patch Description: Binary data
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
> 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 (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; declare
> -p ref; }; f
>
> declare -n ref # why did the value of ref disappear?
>
>
> $
> f() { local var; declare -n ref=var; declare -n ref; declare
> -p ref; }; f
>
> declare -n ref="var"
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
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 in global scope, but not inside a function.
I rebuilt just now, both on mac os x 10.6 and on linux i686, I cannot reproduce
it:
$ f() { unset var; declare -n ref=var; declare -n ref; declare -p ref; }; f
declare -n ref
$ echo $BASH_VERSION
4.4.0(1)-rc2
$ git log -1 | head -1
commit 3475994a81ce49cf3a50b6ceeb5ad719986aa5f4
could you share your environment, platform, etc?
I also debugged unset_builtin, it does some unnecessary calls for no existent
variables, but nothing that would justify this behaviour.
pg
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. this
routine has no idea that the second declare re-declares already declared
reference, and calls make_new_variable. the difference is: make_local_variable
will not create a local variable when there is already one, hence everything
seems fine. make_local_variable should check find_variable_noref(name) and act
accordingly.
It seems half-intended.
pg
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 in global scope, but not inside a function.
Re: Autocompletion problems with nounset and arrays
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
