Answering some of my own questions, asking new ones ...
On Tue, Jul 21, 2026 at 4:51 PM Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> 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
Philippe