Re: Dynamic variable failure & equiv-const strings compare unequal

[Oleg Popov]

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...?