[Bash-completion-devel] [PATCH] check if ruptime is installed

Raphaël raphael.droz at gmail.com
Tue Jun 30 04:28:38 UTC 2015


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)



More information about the Bash-completion-devel mailing list