Re: [PATCH] Restrict named directories to scalar parameters.

I'm sending this anyway without first reading Mikael's reply because I
had it all written.

On Sun, Jun 14, 2026 at 5:23 PM Philippe Altherr
<[email protected]> wrote:
>>
>> Aside:  I suggest adding PS1="" to the input of zsh -fis for the Test/K01 patch.
>
> What is the advantage? It doesn't seem to make any difference.

If the test fails, the PS1 prompt is printed approximately 20 times as
the "Error output" from "zsh -fis".  Set it to empty, it prints once
(for that assignment itself).

> One can distinguish two kinds of named directories:

Er, no.  Or rather, you're reading into this something that was
neither explicit nor intended.

"hash -d" is there to print the named directory table, pre-dating the
zsh/parameter module and $nameddirs.

"hash -d foo=/path" is there only for congruence with "hash" on the
command table.  It was never expected to create a distinct "kind" of
named directory.  That it kinda-sorta does so as a side-effect is an
accidental "feature" at best.  It's actually intentional that you can
make ~foo expand to something that isn't a directory by "hash"-ing foo
into the table.

Finally any semantic assigned to "hash -d nam=val" also has to apply
to "nameddirs[nam]=val" as well.

There actually is another type of named directory, which is a name
that refers to a user's home directory.

> My assumption is that for a parameter-based named directory N, it is in principle expected that ~N and $N remain in sync. The example above shows that this can be violated. However, to the best of my knowledge, it is true as long as one never uses "hash" to modify parameter-based named directories.
> [...]
> If the "hash" command is used to define or update a named directory, then surprisingly all values are accepted:
> [...]
> It's unclear to me whether the fact that the "hash" command doesn't restrict values to ones that start with a "/" is a bug or a feature.

You are correct.  You'll find that using "hash" to update the command
hash table has similar lack of restriction.  Explicitly using "hash"
to put values in the tables was intentionally a "back door" to the
normal behavior, which is why I got a bit annoyed by the thread
downstream of workers/54279. Although I eventually agreed with the
"local variables" argument, my feeling is that as soon as you've
explicitly played around with "hash" you're in unspecified territory.

> A better description of the patch workers/54759 is that it prevents the promotion of named references to named directories.

Very good!  I've no objection to that.  It's also congruent with what
happens here with a non-scalar:

% setopt autonamedirs
% hash -d foo=something
% typeset -a foo=( /1 /2 /3 )
% hash -d
foo=something
%

Although -- even without the patch I don't follow how the nameref is
"promoted" to a namedir, since you can't initialize a nameref to a
value starting with a slash.

> Fixing this without extra infrastructure would be way too expensive; every update of a scalar parameter would have to scan the whole parameter table to check whether there is a named reference flagged with PM_NAMEDDIR that refers to it.

I'm not sure what semantic would be applied to any other "fix".

> To me, restricting parameter-based named directories to scalar parameters looks like the most pragmatic approach.

I found the description and implementation confusing because
parameter-based named directories are already restricted to scalar
parameters -- with the accidental exception of namerefs which slipped
by because structurally they "look like" scalars.

> A better description of the patch workers/54760 is that it prevents the promotion to named directories of (scalar) parameters whose value doesn't start with a "/".

That's already tested in adduserdirs().  What difference does it make
to also test it earlier?