Hi All, I think it is a bug, it is not working as intended at least in the man page, it says.
If that function exists, it is invoked with the original command and the original command's arguments as its arguments, and the function's exit status becomes the exit status of the shell. If that function is not defined, the shell prints an error message and returns an exit status of 127. A function invocation, don't imply a sub shell. Secondly, if yuio insist on going on the subshell path, then $$ and $PPID ought to be setup appropriately, here ther are plain bogus. Third, the argument saying to late we forked already is dumb, it is too late because the sequence hookf = find_function (NOTFOUND_HOOK); execute_shell_function (hookf, wl); is misplaced after the fork, while it should be done before the fork. I provided a fix that no one tested, that don't jeoparise the existing code or behavior, and to respect what a function invocation is. I can survive a "don't fix" well I can fix for myself, but has it is you must at least fix 2 points, fix the doc, sayin the command_not_found_handle() is called in a subshell and fix $$ and $PPID that are bogus in the subshell. BTW fixing $$ and $PPID will take more effort that just placing the hook before the fork, but that's your decision indeed :) I think that either command_not_found_handle() is a gross hack to satisfy command-not-found distro package, and in this case it should simply not be documented in the docco, or else it should be done as specifed i.e a function incovation is not a subshell running a function, that frankly is a bit ridiculous. Cheers, Phi