어쨌든 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
[패치 건너뛰기]