On Thu, Oct 22, 2015 at 05:13:45AM -0700, Linda Walsh wrote: > Oleg Popov wrote: > > On Thu, Oct 22, 2015 at 03:01:06AM -0700, Linda Walsh wrote: > >> [cut] > >> I.e. test output was: > >> Case 2 got/Expected: > >> "222" > >> "1\ 222\ .3\ .4" > >> [cut] > > > > You didn't initialize the array. By the time you do "parts[1]=222" it's > > still empty. And in your previous message you tried to initialize it in > > a subshell. Variables don't retain their values after returning from > > subshells. > ---- > I was testing if dynamic scoping included subshells, I > didn't think so, but that doesn't mean I don't test it. I removed > it though, as it confused the example. > > ip and 'parts' are both initialized in global. > > testor calls (tst0, tst1, tst2 & tst3). > > tst0 & tst1 both call "assignparts" which uses the global > value of $ip to set the global value of parts. I.e. since > neither "ip" nor 'parts' are declared inside of any of the > functions, they should use the top-level global values, no? > > tst2, using the last global value set in tst1, only tries to > change 1 value in 'parts'... i.e. why would 'ip' reference the > global value of 'ip', but not parts? > > ip and parts are declared at the same scope (global), so why > wouldn't the global 'parts' be initialized as well?
$(...) is a subshell. Variables cannot be passed back from a subshell, no matter how and where they are declared. > > Bash uses unquoted characters on the right side of == and != as > > wildcard patterns. For example, [ipaddr] in $exp means "any of i, p, > > a, d, r". You should quote the right operand. > --- > Ahh... or if I quote both sides > using 'printf "%q"' first, that should do the same, no? No. Just use double quotes: [[ $var1 == "$var2" ]] > So, ok, I get that one -- but the first looks sketchy, > as ip and parts are both, only defined at the global level, > thus my expectation that just like it used the global value of > 'ip' for tst0 & tsts1 -- it should have stored the split version > of it in the global value of parts... I really don't get why > it would use the global value as a dynamic in 1 case but not > the other...?