Re: Hiding specials, and namerefs

Philippe Altherr <[email protected]> Thu, 23 Jul 2026 01:41:59 +0200
Newsgroups gmane.comp.shells.zsh.devel
Message-ID <CAGdYchsA6=BSMEfZJ9=ORrRr+X=FX1wmz1-dQuF9WoKDjYotUA@mail.gmail.com>
--00000000000036608a06573bb090
Content-Type: multipart/alternative; boundary="00000000000036608906573bb08e"

--00000000000036608906573bb08e
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, Jul 22, 2026 at 6:24=E2=80=AFAM Bart Schaefer <schaefer@brasslanter=
n.com>
wrote:

> Answering some of my own questions, asking new ones ...
>
> On Tue, Jul 21, 2026 at 4:51=E2=80=AFPM Bart Schaefer <schaefer@brasslant=
ern.com>
> wrote:
> >
> > B02typeset.ztst
> > (eval):typeset:3: SRANDOM: can't change type of autoloaded parameter
> > Was testing: Global -h variable doesn't hide autoload variable
> >
> > I think this one exemplifies the change, the use of -h shouldn't be a
> > silent no-op.  Thoughts?
>
> Clarification here.  The restriction on -h only applies when
> attempting to change the attribute ("type" in the error message is
> wrong, I've corrected) on an existing parameter.   That applies to
> this test because it uses -gh.  If the -g is removed, a new local is
> being created and that is definitely allowed to hide the special from
> the surrounding scope.  I think I have that working.
>
> New question:  Should there be just a warning in this case, or an
> actual error?  An error would change the behavior.
>

I assume that -h is a rather rarely used flag. It's probably even more
rarely used in cases where it fails to hide the targeted parameter. So,
while an error changes the behavior, there are probably extremely few
existing scripts where this would make a difference. On the other hand,
while you develop a new script, an error is somewhat more likely to grab
your attention.


> > Why does it ever make sense to apply -h to a global?  What's the point
> > of this test?
>
> I still have this question.
>

A plain "local SRANDOM" doesn't hide the special SRANDOM but when -h is
added, it does. The tests with -gh are to ensure that whatever logic
triggers this hiding doesn't kick in when -g is present (or when running at
the top-level).

Does it make sense to apply -h to a global? Probably not but it should
still not cause unexpected results.

I noticed that one of the tests is missing a -g and two cases are missing.
The following patch fixes both issues.

- Fix and complete hiding tests
<https://github.com/zsh-users/zsh/compare/master...paltherr:zsh:fix-and-com=
plete-hiding-tests>

Philippe

--00000000000036608906573bb08e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><div><span style=3D"background-color:tran=
sparent">On Wed, Jul 22, 2026 at 6:24=E2=80=AFAM Bart Schaefer &lt;<a href=
=3D"mailto:[email protected]">[email protected]</a>&gt; wro=
te:</span></div></div><div class=3D"gmail_quote gmail_quote_container"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left=
:1px solid rgb(204,204,204);padding-left:1ex">Answering some of my own ques=
tions, asking new ones ...<br>
<br>
On Tue, Jul 21, 2026 at 4:51=E2=80=AFPM Bart Schaefer &lt;<a href=3D"mailto=
:[email protected]" target=3D"_blank">[email protected]</a>=
&gt; wrote:<br>
&gt;<br>
&gt; B02typeset.ztst<br>
&gt; (eval):typeset:3: SRANDOM: can&#39;t change type of autoloaded paramet=
er<br>
&gt; Was testing: Global -h variable doesn&#39;t hide autoload variable<br>
&gt;<br>
&gt; I think this one exemplifies the change, the use of -h shouldn&#39;t b=
e a<br>
&gt; silent no-op.=C2=A0 Thoughts?<br>
<br>
Clarification here.=C2=A0 The restriction on -h only applies when<br>
attempting to change the attribute (&quot;type&quot; in the error message i=
s<br>
wrong, I&#39;ve corrected) on an existing parameter.=C2=A0 =C2=A0That appli=
es to<br>
this test because it uses -gh.=C2=A0 If the -g is removed, a new local is<b=
r>
being created and that is definitely allowed to hide the special from<br>
the surrounding scope.=C2=A0 I think I have that working.<br>
<br>
New question:=C2=A0 Should there be just a warning in this case, or an<br>
actual error?=C2=A0 An error would change the behavior.<br></blockquote><di=
v><br></div><div>I assume that -h is a rather rarely used flag. It&#39;s pr=
obably even more rarely used in cases where it fails to hide the targeted p=
arameter. So, while an error changes the behavior, there are probably extre=
mely few existing scripts where this would make a difference. On the other =
hand, while you develop a new script, an error is somewhat more likely to g=
rab your attention.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote"=
 style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);p=
adding-left:1ex">
&gt; Why does it ever make sense to apply -h to a global?=C2=A0 What&#39;s =
the point<br>
&gt; of this test?<br>
<br>
I still have this question.<br></blockquote><div><br></div><div>A plain &qu=
ot;local SRANDOM&quot; doesn&#39;t hide the special=C2=A0SRANDOM but when -=
h is added, it does. The tests with -gh are to ensure that whatever logic t=
riggers this hiding doesn&#39;t kick in when -g is present (or when running=
 at the top-level).</div><div><br></div><div>Does it make sense to apply -h=
 to a global? Probably not but it should still not cause unexpected results=
.</div><div><br></div><div>I noticed that one of the tests is missing a -g =
and two cases are missing. The following patch fixes both issues.</div><div=
><br></div>-=C2=A0<a href=3D"https://github.com/zsh-users/zsh/compare/maste=
r...paltherr:zsh:fix-and-complete-hiding-tests">Fix and complete hiding tes=
ts</a><br class=3D"gmail-Apple-interchange-newline"><div>=C2=A0</div><div>P=
hilippe</div><div><br></div></div></div>

--00000000000036608906573bb08e--
--00000000000036608a06573bb090
Content-Type: text/plain; charset="US-ASCII"; name="fix-and-complete-hiding-tests.txt"
Content-Disposition: attachment; 
	filename="fix-and-complete-hiding-tests.txt"
Content-Transfer-Encoding: base64
Content-ID: <f_mrwpt16q0>
X-Attachment-Id: f_mrwpt16q0

ZGlmZiAtLWdpdCBhL1Rlc3QvQjAydHlwZXNldC56dHN0IGIvVGVzdC9CMDJ0eXBlc2V0Lnp0c3QK
aW5kZXggMzJlNzljZWQyLi5mZTllYjU1ZWIgMTAwNjQ0Ci0tLSBhL1Rlc3QvQjAydHlwZXNldC56
dHN0CisrKyBiL1Rlc3QvQjAydHlwZXNldC56dHN0CkBAIC0xMTIzLDEyICsxMTIzLDM2IEBACiAK
ICB6bW9kbG9hZCAtdSB6c2gvcmFuZG9tCiAgZWNobyB2PSR7U1JBTkRPTS88LT4vaW50ZWdlcn0K
LSB0eXBlc2V0IFNSQU5ET00KKyB0eXBlc2V0IC1nIFNSQU5ET00KICBlY2hvIHY9JHtTUkFORE9N
LzwtPi9pbnRlZ2VyfQogMDpHbG9iYWwgbm9uIC1oIHZhcmlhYmxlIGRvZXNuJ3QgaGlkZSBzcGVj
aWFsIHZhcmlhYmxlCiA+dj1pbnRlZ2VyCiA+dj1pbnRlZ2VyCiAKKyB6bW9kbG9hZCAtdSB6c2gv
cmFuZG9tCisgZWNobyB2PSR7U1JBTkRPTS88LT4vaW50ZWdlcn0KKyB0eXBlc2V0IC1naCBTUkFO
RE9NCisgZWNobyB2PSR7U1JBTkRPTS88LT4vaW50ZWdlcn0KKzA6R2xvYmFsIC1oIHZhcmlhYmxl
IGRvZXNuJ3QgaGlkZSBzcGVjaWFsIHZhcmlhYmxlCis+dj1pbnRlZ2VyCis+dj1pbnRlZ2VyCisK
KyB6bW9kbG9hZCAtdSB6c2gvcmFuZG9tCisgZWNobyB2PSR7U1JBTkRPTS88LT4vaW50ZWdlcn0K
KyB0eXBlc2V0IFNSQU5ET00KKyBlY2hvIHY9JHtTUkFORE9NLzwtPi9pbnRlZ2VyfQorMDpMb2Nh
bCBub24gLWggdmFyaWFibGUgZG9lc24ndCBoaWRlIHNwZWNpYWwgdmFyaWFibGUKKz52PWludGVn
ZXIKKz52PWludGVnZXIKKworIHptb2Rsb2FkIC11IHpzaC9yYW5kb20KKyBlY2hvIHY9JHtTUkFO
RE9NLzwtPi9pbnRlZ2VyfQorIHR5cGVzZXQgLWggU1JBTkRPTQorIGVjaG8gdj0ke1NSQU5ET00v
PC0+L2ludGVnZXJ9CiswOkxvY2FsIC1oIHZhcmlhYmxlIGhpZGVzIHNwZWNpYWwgdmFyaWFibGUK
Kz52PWludGVnZXIKKz52PQorCiAgem1vZGxvYWQgLXUgenNoL3JhbmRvbQogIGVjaG8gej0keyhN
KSR7KGYpJHsgem1vZGxvYWQgLWFwfX06IypTUkFORE9NKn0KICB0eXBlc2V0IC1nIFNSQU5ET00K
QEAgLTExNDcsMTQgKzExNzEsNiBAQAogMDpHbG9iYWwgLWggdmFyaWFibGUgZG9lc24ndCBoaWRl
IGF1dG9sb2FkIHZhcmlhYmxlCiA+ej1TUkFORE9NICh6c2gvcmFuZG9tKQogPno9U1JBTkRPTSAo
enNoL3JhbmRvbSkKLT52PWludGVnZXIKLQotIHptb2Rsb2FkIC11IHpzaC9yYW5kb20KLSBlY2hv
IHY9JHtTUkFORE9NLzwtPi9pbnRlZ2VyfQotIHR5cGVzZXQgU1JBTkRPTQotIGVjaG8gdj0ke1NS
QU5ET00vPC0+L2ludGVnZXJ9Ci0wOkxvY2FsIG5vbiAtaCB2YXJpYWJsZSBkb2Vzbid0IGhpZGUg
c3BlY2lhbCB2YXJpYWJsZQotPnY9aW50ZWdlcgogPnY9aW50ZWdlcgogCiAgem1vZGxvYWQgLXUg
enNoL3JhbmRvbQo=
--00000000000036608a06573bb090--