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
