Re: BUG: locals remove setopt autonamedirs

[Mikael Magnusson <mikachu@xxxxxxxxx>]

On Tue, Apr 7, 2026 at 1:15 PM Charles Blake <charlechaud@xxxxxxxxx> wrote:
>
> I get the sequence of events and that there is nothing to "restore to".
> I would characterize the "bug" as a zillion completion function authors
> (like the git branch example that made me discover this) control their
> code, not me.  These authors do not know/expect their `local` will
> clobber global state (which in this case is not a global var).
>
> So, your idea 3. creates a burden to submit patches to any that happen
> to use "maybe colliding" names which seems unrealistic.  Your idea 2
> doesn't recognize any value to keeping $<TAB> and ~<TAB> namespaces at
> all separated.  And idea 1 just denies value of the AutoNameDir (A_N_D)
> feature itself.  So, in short, sure for a multi-way interaction problem
> you can just not engage one of the legs of the interaction as a "fix",
> but this just re-states the problem (perhaps more clearly, thanks!).
>
> I should also have said that, while you can always get lucky or with
> foresight be smarter, it can take a while to track down the issue.  Do a
> hash -d in RC files, interact a long time, engage some completion for an
> obscure subcmd, a long time later notice that your hash-d was removed.
> Even once you know of "a problem" you can code up some precmd/preexec
> to trap it, but it might still take quite a while to engage again the
> completer function or subfunction that causes trouble.  It may not even
> be in your shell history which is, after all, not a keystroke history.
> I did not audit all the completers that ship with Zsh, but it would be
> surprising if there aren't quite a few similar problems.
>
> My feeling is that A_N_D is an interactive top-level feature (Philippe's
> reply helped me realize how much, THANK YOU - but docs for the setopt
> also reflect this as prompts & completion are both interactive, top-level
> ideas).  This suggests its utility within shell functions is minimal.
> (Your 1 suggests you think total utility is negligible!).
>
> So, blocking local sets from doing any damage to the hash-d namespace
> seems an ok answer.  This would probably bother no one using A_N_D at
> the top-level for ancient convention leveraging automagic FOOROOT
> prompt abbreviation with the matching reference syntax, `ls ~BAR_HOME`.
>
> Maybe most briefly, the doc fix for A_N_D setopt could be as small as
> "Any parameter that" -> "Any global parameter that".  Would anyone
> oppose that sort of fix?  Do people use A_N_D within functions?  Would
> it cause other notable problems?  Thanks for feedback on this more
> concrete idea for a fix.

(This is not a complete reply to all points.)

Even when AND is not set, attempting to expand ~foo will check if $foo
is an absolute path and populate the hashtable. A subsequent
unset/descope of foo will then remove ~foo from the hashtable. I think
this throws a bit of a wrench in your idea, since this would always
find a local parameter, but on the other hand, it won't override an
already set hashtable entry, so maybe this won't bother you as much in
practice, it's still a bit of an inconsistency though.

I don't *think* setting noautonamedirs in the completion system would
break anything, but I didn't check. Look for
# The standard options set in completion functions.
in compinit if you want to test it. (you would still be unable to use
_comp_caller_options and IFS as named directories, but that's
presumably not an issue).

Of course, preventing the completion system from clobbering your named
dirs won't protect you from any other arbitrary shell functions being
called by custom widgets etc, so this is not intended to be an
argument against your "locals only" idea, but it should be a very
simple and harmless change that'll at least help a bit.