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

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Sun, Jun 14, 2026 at 9:36 PM Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> wrote:
>
> 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.

I think I've finally understood your use of "promoted" here.  You
interpreted PM_NAMEDDIR as equating a parameter with a nameddir table
entry in both directions ("remain in sync").  That's not the case; a
parameter is never a named directory; an entry in the nameddir table
is a named directory.  PM_NAMEDDIR makes a parameter into a mechanism
for assigning values to the nameddir table.

If I recall my history correctly (which I've demonstrated several
times isn't always the case), the order of events went something like
this:
  1. ~username expands to a user's home directory (feature from csh).
  2. If the user isn't local, it takes a long time for the operating
system to look up the directory.  Can we cache the result?
  3. Now we've got a table that maps usernames to directories.  Can we
put things other than usernames in that table?
  3a. ... because it's neat the way prompts can abbreviate a path if
it appears in that table.
  3b. ... and an easy way to set up that table.  Parameters with
pathnames as the value?
  4. Great, but it's icky to explicitly do ~parm at least once to get
the abbreviation effect in my prompt.  So, AUTO_NAME_DIRS.
  4. Hey, this table is exactly like the command table, and we can
poke that with the "hash" command.  Add "hash -d".

> > 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?

The difference is that adduserdir() inverts the test:  It checks for
value not starting with a "/" and removes the table entry.  The
PM_NAMEDDIR flag doesn't matter here unless you later toggle off
AUTO_NAME_DIRS, leaving some parameters invisibly tied to table
update; the important bit is the call to adduserdir().

This all seems to come back to the documentation for AUTO_NAME_DIRS
use of the phrase "Any parameter ... immediately becomes a name".
That's not what happens.  The parameter never "becomes" anything other
than a one-way updater for the nameddir table.  I suppose no one has
ever considered the distinction to be important to the user
experience.

The question is ...

setopt autonamedirs
foo=bar  # is it important that foo is (or is not yet) linked to the
nameddir table?
foo=$HOME/foo # because now it's linked ...
foo=bar  # and now this (forever) has a different side-effect than before