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

[Linda Walsh]

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?



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

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