Re: Indirect parameter access combined with Assign Default Values
This might have the same fix. I guess Bash only checks for valid
variable names during expansion or initial assignment.
$ bash -xc 'typeset -n x; x=@ x=(ha ha); typeset -p @'
+ typeset -n x
+ x=@
+ x=(ha ha)
+ typeset -p @
declare -a @='([0]="ha" [1]="ha")'
Bash eventually catches it if you try using the variable so the harm is
minimal. I suppose you could wreck things for somebody evaluating the
output.
$ typeset -n x; x="_; y" x=foo; typeset -p "${!x}"; eval "$(typeset -p
"${!x}")"; echo "$y"
+ typeset -n x
+ x='_; y'
+ x=foo
+ typeset -p '_; y'
declare -- _; y="foo"
++ typeset -p '_; y'
+ eval 'declare -- _; y="foo"'
++ declare -- _
++ y=foo
+ echo foo
foo
--
Dan Douglas
Re: 'local -x VARIABLE' does not clear variable for subprocesses
On 5/7/14, 2:10 AM, Dan Douglas wrote:
> On Monday, May 05, 2014 11:18:50 AM Chet Ramey wrote:
>> The idea behind the bash-4.3 behavior is that the placeholder local
>> variable isn't set, and doesn't really exist. It doesn't shadow a
>> global variable with the same name until it gets a value. The bash-4.2
>> behavior was inconsistent: variables with attributes but without values
>> weren't quite set (value == 0x0, but still visible) and weren't quite
>> unset. I tightened up the some of the consistency starting with bash-4.3
>> beta. I'm sure there are still inconsistencies there (and, in fact, I
>> found one while looking at this).
>
> By "doesn't shadow" you mean that it _does_ hide the global right? Localizing
> a variable should cover up globals and variables in parent scopes even if
> they
> aren't given a value. That seems true in bash 4.3 and nearly every shell
> (except dash).
I mean that a local variable that has not been given a value, and is
technically unset, should not shadow a global variable with the same
name. Run the following script, after accounting for the local/typeset
differences between shells. The results are less conclusive than you think.
export VAR1=abc VAR2=abc
f()
{
local VAR1; local VAR2
echo local: ${VAR1-unset1} ${VAR2-unset2}
printenv VAR1 ; printenv VAR2
}
f
Shells that shadow print `local: unset1 unset2'. Shells that don't shadow
print `local: abc abc'. Everyone except bash-4.2 seems to print
`abc\nabc' with the printenv calls.
Shadow: bash-4.3, mksh, posh
Doesn't shadow: ksh93, dash, freebsd sh
zsh is off doing its own thing and just prints `local:'. I presume that
means it silently assigns a null value.
> If you want to set an attribute without localizing the variable then you've
> always been able to use "export" or "readonly" in place of "local -x".
Sure, but the OP wants to do exactly the opposite, and more.
> I also wouldn't want this example to change so that ref always appears set.
> The localized x in g should hide f's x even with no value.
namerefs are their own special beasts.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: Indirect parameter access combined with Assign Default Values
On 5/7/14, 6:45 AM, Dan Douglas wrote: > This might have the same fix. I guess Bash only checks for valid > variable names during expansion or initial assignment. Thanks, I already fixed this. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
segfault if nameref set on local variable
Another one to do with namerefs. :-)
Looks like it's when the target of the ref is local to the same scope.
$ gdb -q -ex 'run -c "function f { typeset x; typeset -n x; x=y; }; f"' ./bash
Reading symbols from ./bash...done.
Starting program: /home/smorg/doc/programs/bash/bash -c "function f { typeset
x; typeset -n x; x=y; }; f"
warning: Could not load shared library symbols for linux-vdso.so.1.
Do you need "set solib-search-path" or "set sysroot"?
Program received signal SIGSEGV, Segmentation fault.
strlen () at ../sysdeps/x86_64/strlen.S:106
106 movdqu (%rax), %xmm12
(gdb) bt
#0 strlen () at ../sysdeps/x86_64/strlen.S:106
#1 0x004b4842 in mbschr (s=0x0, c=91) at mbschr.c:60
#2 0x00473a35 in valid_array_reference (name=0x0) at arrayfunc.c:826
#3 0x00441fae in bind_variable_internal (name=0x72c538 "x",
value=0x72c498 "y", table=0x73d9e8, hflags=0, aflags=0)
at variables.c:2533
#4 0x004424d0 in bind_variable (name=0x72c558 "x", value=0x72c498 "y",
flags=0) at variables.c:2662
#5 0x00458139 in do_assignment_internal (word=0x73dca8, expand=1) at
subst.c:2866
#6 0x00458247 in do_word_assignment (word=0x73dca8, flags=0) at
subst.c:2906
#7 0x0046651c in expand_word_list_internal (list=0x739fe8, eflags=31)
at subst.c:9623
#8 0x00465aaa in expand_words (list=0x739fe8) at subst.c:9234
#9 0x0043bc80 in execute_simple_command (simple_command=0x73d2c8,
pipe_in=-1, pipe_out=-1, async=0, fds_to_close=0x73c948)
at execute_cmd.c:3991
#10 0x00435f9f in execute_command_internal (command=0x73d288,
asynchronous=0, pipe_in=-1, pipe_out=-1, fds_to_close=0x73c948)
at execute_cmd.c:787
#11 0x00438f08 in execute_connection (command=0x73d088, asynchronous=0,
pipe_in=-1, pipe_out=-1, fds_to_close=0x73c948)
at execute_cmd.c:2487
#12 0x004362f5 in execute_command_internal (command=0x73d088,
asynchronous=0, pipe_in=-1, pipe_out=-1, fds_to_close=0x73c948)
at execute_cmd.c:945
#13 0x004362cb in execute_command_internal (command=0x73d048,
asynchronous=0, pipe_in=-1, pipe_out=-1, fds_to_close=0x73c948)
at execute_cmd.c:937
#14 0x0043ced9 in execute_function (var=0x739928, words=0x739e48,
flags=0, fds_to_close=0x73c948, async=0, subshell=0)
at execute_cmd.c:4530
#15 0x0043d3b6 in execute_builtin_or_function (words=0x739e48,
builtin=0x0, var=0x739928, redirects=0x0, fds_to_close=0x73c948,
flags=0) at execute_cmd.c:4760
#16 0x0043c22f in execute_simple_command (simple_command=0x73ca48,
pipe_in=-1, pipe_out=-1, async=0, fds_to_close=0x73c948)
at execute_cmd.c:4161
#17 0x00435f9f in execute_command_internal (command=0x73ca08,
asynchronous=0, pipe_in=-1, pipe_out=-1, fds_to_close=0x73c948)
at execute_cmd.c:787
#18 0x00438f08 in execute_connection (command=0x73cac8, asynchronous=0,
pipe_in=-1, pipe_out=-1, fds_to_close=0x73c948)
at execute_cmd.c:2487
#19 0x004362f5 in execute_command_internal (command=0x73cac8,
asynchronous=0, pipe_in=-1, pipe_out=-1, fds_to_close=0x73c948)
at execute_cmd.c:945
#20 0x00490145 in parse_and_execute (string=0x73bd08 "function f {
typeset x; typeset -n x; x=y; }; f",
from_file=0x4dcc50 "-c", flags=4) at evalstring.c:367
#21 0x0041f6ee in run_one_command (command=0x7fffd5fe "function f {
typeset x; typeset -n x; x=y; }; f") at shell.c:1339
#22 0x0041e9e0 in main (argc=3, argv=0x7fffd108,
env=0x7fffd128) at shell.c:694
--
Dan Douglas
Re: segfault if nameref set on local variable
On 5/7/14, 10:21 AM, Dan Douglas wrote:
> Another one to do with namerefs. :-)
>
> Looks like it's when the target of the ref is local to the same scope.
>
> $ gdb -q -ex 'run -c "function f { typeset x; typeset -n x; x=y; }; f"' ./bash
Thanks for the report. This is an abstraction layer violation (and a long-
lived one; it's been this way for years). I've attached a patch for people
to play with.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
*** ../bash-4.3-patched/variables.c 2014-02-14 11:55:12.0 -0500
--- variables.c 2014-05-07 10:53:57.0 -0400
***
*** 2198,2205
old_var = find_variable (name);
if (old_var && local_p (old_var) && old_var->context == variable_context)
! {
! VUNSETATTR (old_var, att_invisible); /* XXX */
! return (old_var);
! }
was_tmpvar = old_var && tempvar_p (old_var);
--- 2260,2264
old_var = find_variable (name);
if (old_var && local_p (old_var) && old_var->context == variable_context)
! return (old_var);
was_tmpvar = old_var && tempvar_p (old_var);
Re: 'local -x VARIABLE' does not clear variable for subprocesses
On Wednesday, May 07, 2014 10:04:11 AM Chet Ramey wrote: > On 5/7/14, 2:10 AM, Dan Douglas wrote: > > By "doesn't shadow" you mean that it _does_ hide the global right? > > Localizing > > a variable should cover up globals and variables in parent scopes even if > > they > > aren't given a value. That seems true in bash 4.3 and nearly every shell > > (except dash). > > I mean that a local variable that has not been given a value, and is > technically unset, should not shadow a global variable with the same > name. Run the following script, after accounting for the local/typeset > differences between shells. The results are less conclusive than you think. Ah ok I thought you meant the opposite. So not the "dash effect" where the value of a global is always still visible until a local gets a value. Yes I see the results are all over the place. Basically what the big script linked in my previous post attempted to test, though ksh lexical scope makes comparison hard and not so meaningful. Your bash 4.3 way makes sense to me (leaving the global in the environment but shadowing the local). -- Dan Douglas
Re: segfault if nameref set on local variable
On Wednesday, May 07, 2014 10:58:42 AM Chet Ramey wrote:
> On 5/7/14, 10:21 AM, Dan Douglas wrote:
> > Another one to do with namerefs. :-)
> >
> > Looks like it's when the target of the ref is local to the same scope.
> >
> > $ gdb -q -ex 'run -c "function f { typeset x; typeset -n x; x=y; }; f"'
> > ./bash
>
> Thanks for the report. This is an abstraction layer violation (and a long-
> lived one; it's been this way for years). I've attached a patch for people
> to play with.
...And I noticed the patch pop up on my screen from Gentoo's CVS feed before
noticing my own inbox. Works great here.
--
Dan Douglas
Re: 'local -x VARIABLE' does not clear variable for subprocesses
On 5/7/14, 11:43 AM, Dan Douglas wrote: > On Wednesday, May 07, 2014 10:04:11 AM Chet Ramey wrote: >> On 5/7/14, 2:10 AM, Dan Douglas wrote: >>> By "doesn't shadow" you mean that it _does_ hide the global right? >>> Localizing >>> a variable should cover up globals and variables in parent scopes even if >>> they >>> aren't given a value. That seems true in bash 4.3 and nearly every shell >>> (except dash). >> >> I mean that a local variable that has not been given a value, and is >> technically unset, should not shadow a global variable with the same >> name. Run the following script, after accounting for the local/typeset >> differences between shells. The results are less conclusive than you think. > > Ah ok I thought you meant the opposite. So not the "dash effect" where > the value of a global is always still visible until a local gets a > value. No, that's what I'm talking about. The local is unset until it gets a value, so the global is still visible (not shadowed). This is not what bash-4.3 does, but I was thinking about experimenting with a change to make bash-4.3 behave like ksh93 and dash. I put some code in so I can call different functions in the `find_variable' family to get different behavior, so I will experiement that way. > Yes I see the results are all over the place. Basically what the big > script linked in my previous post attempted to test, though ksh lexical > scope makes comparison hard and not so meaningful. Your bash 4.3 way > makes sense to me (leaving the global in the environment but shadowing > the local). It makes sense if you know the internals and what's going on, but it's kind of difficult to explain. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
