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

On Mon, Jun 15, 2026 at 5:40 PM Bart Schaefer <[email protected]> wrote:
>
> On Sun, Jun 14, 2026 at 9:36 PM Bart Schaefer <[email protected]> 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

I guess it only matters to users who used hash foo=/bar explicitly,
and would like unrelated parameters to not interfere. If they have
AUTONAMEDIRS set and set foo to a directory, then I guess they can't
complain here. However, maybe it would be reasonable to remove the
PM_NAMEDDIR flag from foo after it is found to not be a named dir
anymore? (such that after your foo=bar assignment, I can restore my
hash foo=/bar and subsequent assignments to foo don't erase it). I
don't use autonamedirs (if that wasn't already obvious), so I'm not
sure if you'd expect foo=bar to ensure ~foo was empty for some reason
(eg, even if ~foo was set via hash, and $foo was never a path).

-- 
Mikael Magnusson