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

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Sun, Jun 14, 2026 at 9:04 PM Mikael Magnusson <mikachu@xxxxxxxxx> wrote:
>
> The table supports exactly one feature, mapping a string (the name) to
> another string (the path). Things can be added to this table in
> various ways, but there is always just one type of entry in the table.

That's not precisely true because each entry in the table does have a
"flags" field and the ND_USERNAME flag does have semantics similar to
a "type".

> The table has no knowledge of PM_NAMEDDIR at any point.

This, however, is the case.

> I agree that setting PM_NAMEDDIR on a nameref seems insane. It's a
> property of a parameter that has a value. You can have a nameref
> pointing to such a parameter, and then the nameddir would be updated
> when you set its value, either through the parameter or through the
> nameref. Right?

Yes, and that does happen.  But ref=var followed by ~ref no longer
causes $var to become a nameddir, which if I'd thought of it at all
I'd have tried to avoid in the first place.

> I'm sure I'm repeating myself at this point, but using "hash -d
> foo=/bar" and "foo=/bar" will both set the value of ~foo to /bar,
> there is no "type of named directory" in play at any point. You are
> simply assigning to the same thing multiple times.

This doesn't happen for table entries with the ND_USERNAME flag, I
believe.  That is, you can't fool zsh into renaming someone's home
directory ... though you can HIDE a home directory by creating the
nameddir entry first.

> > The documentation of the AUTO_NAME_DIRS option states that only parameters whose value is an absolute directory become named directories. However, the current implementation promotes all scalar parameters and all named references to named directories (i.e., flags them with PM_NAMEDDIR) whenever their value is initialized or updated.
>
> I can agree that the current behavior doesn't seem to agree with the manpage.

I'm still disgruntled by this notion of "promotion" to a nameddir.
The only thing the PM_NAMEDDIR flag means is to update the nameddir
table when the parameter changes.  If its name is not a key in the
table, it's not a nameddir, whether the flag is set or not.

> That said, I would prefer using only the hash builtin to modify the
> table and that it had nothing to do with parameters whatsoever. The
> whole point of having a separate ~ namespace to me is that I can avoid
> littering the $ namespace. Maybe while we're messing around in this
> area

Please note this discussion is ultimately about whether we are messing
around or not.

> nobody would mind if I also add an option to disable ~foo
> automagically checking if $foo has a path in it and setting ~foo,
> since you currently cannot disable this?

I don't mind in principle, but what practical effect would this have?
After "hash -d foo=..." the check for $foo containing a path is
skipped because foo is immediately found in the table ... no?