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

[Mikael Magnusson <mikachu@xxxxxxxxx>]

On Tue, Jun 16, 2026 at 1:45 AM Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> wrote:
>
> On Mon, Jun 15, 2026 at 9:27 AM Mikael Magnusson <mikachu@xxxxxxxxx> wrote:
> >
> > On Mon, Jun 15, 2026 at 5:40 PM Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> wrote:
> > >
> > > 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.
> > [...] maybe it would be reasonable to remove the
> > PM_NAMEDDIR flag from foo after it is found to not be a named dir
> > anymore?
>
> Consider this sequence:
>
> setopt autonamedirs
> dirname=$HOME/mynameddir
> unsetopt autonamedirs
> hash -d dirname=/tmp

I guess this sequence is equivalent to
# don't setopt autonamedirs
dirname=$HOME/mynameddir
echo ~dirname
hash -d dirname=/tmp

right? Eg, dirname ends up with the PM_NAMEDDIR flag.

> Now assign something to dirname.  Describe what should happen
> -- when the value begins with a slash
~dirname -> $dirname

> -- when the value does not begin with slash
~dirname removed, but $dirname gets PM_NAMEDDIR removed. I am now free
to use hash dirname=whatever and subsequent assignments to dirname
don't interfere.

> For "unset dirname", does it behave like the latter case?  Why or why not?
I can think of reasons for either case here.
former:
- I realize that dirname has the PM_NAMEDDIR flag and want to remove
it without affecting my ~dirname hash.
latter:
- unset dirname is like giving dirname the empty value, and that would
clear ~dirname.
In both cases I would expect the PM_NAMEDDIR flag to be removed though.

> Now describe what happens in those 3 cases when that last "hash -d" is
> "hash -r".
In this case our custom hash entry has been cleared, but I don't think
the results should be any different from what I described above. The
"former" argument is obviously weaker here.

> Now dispense with autonamedirs but use ~dirname before "hash -d" or
> after "hash -r".
Ah, I already did this and consider this equivalent, since you ended
your state with autonamedirs disabled.

> What I'm digging for is:
>
> > (such that after your foo=bar assignment, I can restore my
> > hash foo=/bar and subsequent assignments to foo don't erase it).
>
> To make that actually work, I believe at some point in a few of the
> cases above you end up sweeping the entire parameter table to clear
> all PM_NAMEDDIR flags.

I didn't mean that hash foo=/bar should remove PM_NAMEDDIR from $foo,
just that setting a non-dir to $foo should remove the flag. In case
that was unclear.

> I think your earlier suggestion, which I'm going to state as:
>   Enable ~name only for user homes and existing nameddir entries
> Is the only approach that begins to make sense, and even then only if
> autonamedirs is avoided.
>
> I've started a few times down the thought-path of doing away with
> PM_NAMEDDIR entirely, but that leaves us with no way to remove entries
> from nameddir once they exist (except for the very hackish "nogob
> unset nameddir[name]" or a blanket "hash -r").

I also forget unhash exists sometimes, but it does.

> As a further aside,
>   hash [-d] name
> does nothing it all ... it neither prints the entry for name, nor
> changes it.  That does feel like something that could be changed.

It enters name into the respective hash table via the normal method, eg
hash -d -r; hash -d bart # now ~bart exists again

You can give -v if you want the entry to be printed, but it won't be a
no-op print, it will still attempt to add the entry if it didn't exist
(and print an error if it can't).

-- 
Mikael Magnusson