zsh bug with local variables?

zsh bug with local variables?

[Greg Klanderman]

I'm running zsh-3.1.4 (zsh -f) on solaris 2.5.1, and type:

pochacco% function foo () { local foobar ; foobar=( "$@" ) ; bar ; echo "foobar= ${foobar[*]}" ; }
pochacco% function bar () { local foobar ; foobar=( foo bar ) ; }
pochacco% foo hello there
foobar= foo bar

Is this a bug?  Notice the outer local variable has been set when 
only the inner one should have been.  Bash 2.02 does handle this
as expected.

Another random question, is there a clean way to test whether there
is a function defined with a given name?

thanks,
Greg

ps- zsh is excellent, thanks!

PATCH: 3.1.4: Re: zsh bug with local variables?

[Peter Stephenson]

Greg Klanderman wrote:
> I'm running zsh-3.1.4 (zsh -f) on solaris 2.5.1, and type:
> 
> pochacco% function foo () { local foobar ; foobar=( "$@" ) ; bar ; echo "foob
> ar= ${foobar[*]}" ; }
> pochacco% function bar () { local foobar ; foobar=( foo bar ) ; }
> pochacco% foo hello there
> foobar= foo bar
> 
> Is this a bug?  Notice the outer local variable has been set when 
> only the inner one should have been.  Bash 2.02 does handle this
> as expected.

It certainly looks like one to me.  The following patch does what I originally
expected when I added the local variable system.  Unfortunately, I don't
have a lot of faith in the whole typeset-set/unset-local parameter business
(and never did have).  That probably isn't the answer you want :-).
I've added an essay to the patch to prevent future mishaps.

> Another random question, is there a clean way to test whether there
> is a function defined with a given name?

testfunc() { functions $1 >& /dev/null && echo yes || echo no }

(I've been forgetting to put PATCH: on my patches, sorry.  At least
the mailing list archive is now available again.)

*** Src/params.c.local	Sun May 31 15:12:58 1998
--- Src/params.c	Tue Aug 18 16:31:33 1998
***************
*** 1339,1345 ****
  	    unsetparam_pm(altpm, 1, exp);
      }
  
!     if (locallevel >= pm->level && (pm->flags & PM_SPECIAL))
  	return;
  
      paramtab->removenode(paramtab, pm->nam); /* remove parameter node from table */
--- 1339,1352 ----
  	    unsetparam_pm(altpm, 1, exp);
      }
  
!     /* If this was a local variable, we need to keep the old     *
!      * struct so that it is resurrected at the right level.      *
!      * This is partly because when an array/scalar value is set	 *
!      * and the parameter used to be the other sort, unsetparam() *
!      * is called.  Beyond that, there is an ambiguity:  should	 *
!      * foo() { local bar; unset bar; } make the global  bar	 *
!      * available or not?  The following makes the answer "no".   */
!     if (locallevel >= pm->level)
  	return;
  
      paramtab->removenode(paramtab, pm->nam); /* remove parameter node from table */

-- 
Peter Stephenson <pws@ifh.de>       Tel: +39 50 844536
WWW:  http://www.ifh.de/~pws/
Gruppo Teorico, Dipartimento di Fisica
Piazza Torricelli 2, 56100 Pisa, Italy

Re: PATCH: 3.1.4: Re: zsh bug with local variables?

[Bart Schaefer]

On Aug 18,  4:51pm, Peter Stephenson wrote:
} Subject: PATCH: 3.1.4: Re: zsh bug with local variables?
}
} !     /* If this was a local variable, we need to keep the old     *
} !      * struct so that it is resurrected at the right level.      *
} !      * This is partly because when an array/scalar value is set	 *
} !      * and the parameter used to be the other sort, unsetparam() *
} !      * is called.  Beyond that, there is an ambiguity:  should	 *
} !      * foo() { local bar; unset bar; } make the global  bar	 *
} !      * available or not?  The following makes the answer "no".   */

That's consistent with the 3.0.5 behavior.  Remember my namedir tests?
With this patch applied, 3.1.4 behaves exactly like 3.0.5 again:

zagzig% namedir_test
zsh 3.1.4
TEST 1
namedir1: test1=/etc
namedir1: test1=/etc
namedir2: test1=/etc
namedir1: test1=/etc
namedir3:
namedir1: test1=/etc
namedir4:
TEST 2
namedir1: test2=/etc
namedir1: test2=/etc
namedir2: test2=/etc
namedir1: test2=/etc
namedir3:
namedir1: test2=/etc
namedir4: test2=/usr/bin

(I still think the namedir4 behavior is wrong.)

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com