Re: command_not_found_handle not run when PATH is empty

[Robert Elz]

    Date:        Thu, 09 Mar 2023 09:26:18 +0100
    From:        Andreas Schwab <schwab@suse.de>
    Message-ID:  <mvm5ybagwk5.fsf@suse.de>

  | But an unset PATH is *not* the same as PATH=.

That might be true, but POSIX says:

        If PATH is unset or is set to null, or if a path prefix in PATH
        contains a <percent-sign> character ('%'), the path search is
        implementation-defined.

Ignore the "or if" part, but what the rest of that says is that bash
(or any other shell) gets to define where to search (which could be
nowhere, or '.', or some standard path setup) when PATH is unset, or
(as in the case from the OP) when PATH=''

So, if bash wants to define PATH= as being the same as PATH=. that's
just fine - and more than that, is probably the right thing to do as
PATH=:/bin is the same as PATH=.:/bin and PATH=/bin: is the same as
PATH=/bin:. and PATH=/bin::/usr/bin is ...  - an empty component of PATH
is treated as '.' (always has been in all Bourne shells), PATH= is really
just a path with only one component, which is empty.

The case for an unset PATH is not so clear, and either doing no search
at all, or searching a system defined standard command path, is probably
a better choice in those cases, rather than treating it as '.' (two ways
to say '.' is arguably overkill already, three is too much).   But that
case isn't the OP's case, so is irrelevant in the current discussion.

kre

ps: whatever bash decides to do, it should be consistent for all uses of
PATH of course, not different for searching then for completion, or for
"not found" handlers.