不知怎的,v
在调用后会被取消设置f
。
$ zsh -xc 'v=1; f() { local v; v=2 true; }; f; typeset -p v'
+zsh:1> v=1
+zsh:1> f
+f:0> local v
+f:0> v=2 +f:0> true
+zsh:1> typeset -p v
zsh:typeset:1: no such variable: v
这里是要旨我的原始复制报告。
我做到了电子邮件[电子邮件受保护],但我还没有收到任何回复。
答案1
这确实是一个错误。您举报此事是正确的。
然后通过此提交修复了它:https://sourceforge.net/p/zsh/code/ci/d946f22a4cd2eed0f3a67881cfa57c805703929c/这将包含在下一版本中。
这是zsh
维护者的解释:
On Wed, 2019-08-14 at 10:37 +0100, Stephane Chazelas wrote: > 2019-08-08 20:38:05 +0430, Aryn Starr: > Now, that being said, as discussed on U&L it looks like a bug > indeed and a shorter reproducer is: > > $ zsh -xc 'v=1; f() { local v; v=2 true; }; f; typeset -p v' > +zsh:1> v=1 > +zsh:1> f > +f:0> local v > +f:0> v=2 +f:0> true > +zsh:1> typeset -p v > zsh:typeset:1: no such variable: v > > Most likely, that's the "v=2 true" (where "true" is a builtin) that ends up > unsetting the "v" from the global scope. Yes, the saved version of "v" that we restore after the builtin is missing the pointer back to the version of v in the enclosing scope. So it's not only not shown as set, it will leak memory. This simply preserves that pointer in the copy, but this assumes we've correctly blocked off the old parameter from being altered inside the function scope --- if we haven't that preserved old pointer is going to get us into trouble. However, if we haven't that's already a bug, so this shouldn't make things worse. pws
[跳过补丁]