On Tue, Jun 23, 2015 at 10:42:55PM +0200, isabella parakiss wrote: > Besides, as previously mentioned, people may want to run their custom > completion functions from that handle.
You assumed loudly something which does not appear so obvious. There *is* a point in having command_not_found_handle in an *interactive* shell and although nothing seems special about non-interactive shell (according to the bash documentation), the real use of this handler needs to be deeply considered and even more in the case of the code of a command completion. A lot of programs put a limit to recursion depth, deep "hooking" abilities often bring this can of issues. bash defaults is to trigger command_not_found_handle inside a non-interactive completion handler but it does not mean that said bash completions have to support this "feature", especially since (like Ville already wrote) completion: - may be provided upstream - may not rely on shell (eg: perl's completion relying on perl) - may not assume being interrupted - may do other subtle things I can't thing about like signal, exported or readonly variables, $FUNCNEST, bash setting ... ? How is "legitimate" to ask for bash completions to assume that command_not_found_handle could defined? IHMO in a completion handler (or maybe more generally, when $BASH_SUBSHELL > 0), you should not assume "too much" about nested bash instances since they may set or behave according to other environment, modes, settings and error-handling and code practices ... more restrictive than the top-level plain and full-featured shell Maybe init_completion or bash_completion.sh could simply do: > unset command_not_found_handle to make explicit assumptions, as they already do: > shopt -s extglob progcomp > I really think this is the *wrong* way to solve the problem. > It's surprising that you don't understand it. These are cases where it's *easier* to treat command non-existence as non-special type of failure. These are case when we are only interested by the optional output of said command rather than it's return code or whether the command exist at all. (I realized lately that the thread was already a week old but I don't intend to feed fire) _______________________________________________ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/bash-completion-devel