Re: command_not_found_handle() flaw

[Phi Debian]

Hi All,

Ok I got the picture now, and I owe you some apologize, but with what I got
in front of me (ubuntu 20.04, bash-git latest) mistake from my side was
easy to do.

Regarding the docco, I admit I got the latest bash source (git) BUT I read
the ubuntu 20.04 doc, that still DON'T mention the separate context (for
the 2 years to come :) ), when reading the 5.x latest bash.1 I reckon the
separate context is there, and up to that point (i.e with old doc in mind)
I could not think that this function was a "separate context"

Then the $$ vs $BASHPID confusion was a consequence of this.

So now the questionning about the implementation of this 'feature' that
seems to be, 'how to do something when a command is not found in an command
interpreter' and the idea behind is the implementation of a mechanism for
command interpreter (at large) to be able to suggest 'distro package
suggestion', or if the goal was not that at least this is how it is used a
the moment.

To me, to fullfil the feature as stated here, 2 implementation where
possible.

- A pure 'handler' like a trap handler, then executed in the top shell
context. This handler has then to be installed (sourced) in the shell
startup (similar to now)
- A pure script/prog invocation, then in a separate process, then separate
context. Something along the line of
BASH_CNF && $BASH_CNF "$@", this is pseudo code done in
execute_disk_command(), i.e check for BASH var for user liking doing CNF
and if so, simply prepand $BASH_CNF (likely to be command-not-found)  (as
currently it prepand command_not_found_handle) and retry
search_for_command() once with the new run string, this way it would go and
chase command-not-found in whatever place distro place it in the PATH, (Or
user replacement), The distro would simply source
BASH_CNF=command-not-found, and the user have control in her rc path for
sdjusting the setting.

A function invocation in a sub-shell (separate context) is the worst idea,
simply because
1) It require doc fixup, what was done for 5.x and a clear refresh of the
users mind, misleading path.
2) It need some ugly code in execute_disk_command()

I think in the current logic (distro sugestion) a pure chase of
command-not-found in PATH would have been simpler to document and implement.

Yet I personnaly prefer the 'trap logic', because it serve the same
services as current (distro sugestions) yet open the door for other things,
like function autoloading, customised error handling on CNF.

After all a CNF situation is an error, and a trap 'blah' ERR is correctly
trigged, and the handler executed in the top shell context. But we don't
want to implement CNF handling via trap ERR, because trap '' ERR is a bit
heavy.
So as an 'enhancemen't 'may be dreamin', having an ERRCNF pseudo signal
would be ideal, could even keep the 'old' half hearted
command_not_found_handle() (not a handler, not a script) and work together.
I noted the subtility in that function name, it is not called
command_not_found_handler() just because it is not an handler :) that's
what should have warned me from the beginning :)


Anyway, I will cope with that, and I have an implementation of lazy
function autoload that works with the current implementation,
command_not_found() simply sending a signal to main shell, saying we got a
CNF :) ugly but it works.

I love bash and all the evolution of it.
Cheers,
Phi