fix(gcc): explicitly check existence of the commands

[akinomyoga]

When at least one of the commands cc, c++, f77, and f95 is not found in the system, on the first load of gcc completions, command_not_found_handle hook (typically set by distributions) is invoked in the middle of completion, breaks the terminal layout by outputting messages, and eats user inputs. This PR fixes the issue by checking the existence of commands before running these commands.

As suggested in #390, maybe we could ask for some support by the upstream Bash, e.g., an option to turn off the command_not_found_handle hook or just totally disabling command_not_found_handle for the programmable completions. Nonetheless, I think we can eliminate the chances of unintended command_not_found_handle calls for the existing Bash versions.

Refs.

• Check that ruptime is present before calling #390
• Two potential bugs akinomyoga/ble.sh#192
• [bash-completion, command_not_found_handle] gcc autoreplace terminal bricking akinomyoga/ble.sh#203

Sorry, this PR is again draft. I'm kind of busy so let me open the PR so I don't forget about it and revisit it later. I think I need to survey similar cases in the codebase. Also, I need to test it.

[akinomyoga]

It's not yet completed, but I think I need to ask for the opinion from @scop. Let me change this from a Draft PR to a normal PR.

There are still many other cases that can be affected by command_not_found_handle even in the main file, bash_completion: see e.g. functions _mac_addresses, _available_interfaces, and _ip_addresses, which try to run commands that might not be available in the system.

Instead of prepending type -- CommandName &>/dev/null && for every such case, maybe we should introduce a helper function like this:

_comp_command() {
  type -- "$1" &>/dev/null && command "$@"
}

What do you think?

[scop]

My general mindset is still the same as in #390; we'd have to do this in a lot of places, and I'm not a fan of that at all. But I suppose our options are

1. Continue to declare this is not a problem we want to address
2. Do something like the suggestion here
3. See if the exit hook mechanism from feat: implement BASH_COMPLETION_FINALIZE_HOOKS #739 or something like that, if we end up merging it, could be used to restore the command_not_found_handle we've stashed away let's say in _init_completion.

Regarding 1), note that we already have a recipe for command_not_found_handle authors how to make their functions not interfere with completions:

bash-completion/README.md

Line 257 in a855714

**Q. bash-completion interferes with my `command_not_found_handler` function!**

. I filed #774 to improve on that somewhat. I think promoting this approach and submitting patches to distros' implementations where needed would still be my favourite option. (ISTR having submitted some such patches already a long time ago, but could be mistaken too.)

[akinomyoga]

My general mindset is still the same as in #390; we'd have to do this in a lot of places, and I'm not a fan of that at all.

I was thinking that maybe we can add workarounds only when there is a report. If we would like to cover them at once, we can actually search for /dev/null because there should be always '&>/dev/null' or 2>/dev/null when we know in advance that the command might fail.

But I suppose our options are

1. Continue to declare this is not a problem we want to address
2. Do something like the suggestion here
3. See if the exit hook mechanism from feat: implement BASH_COMPLETION_FINALIZE_HOOKS #739 or something like that, if we end up merging it, could be used to restore the command_not_found_handle we've stashed away let's say in _init_completion.

(ISTR having submitted some such patches already a long time ago, but could be mistaken too.)

I received reports for Fedora 35 (akinomyoga/ble.sh#192) and 36 (akinomyoga/ble.sh#203). In Fedora, the command_not_found_handle is provided by the package PackageKit-command-not-found. This PackageKit-command-not-found seems to be not distribution specific but also used by Ubuntu etc., so maybe we should report it to PackageKit instead of reporting it to distributions (or maybe you have already done that)?

[akinomyoga]

OK, I found it: PackageKit/PackageKit#67

The code is still there in the current version, but somehow it still prints an error message. Edit: Ah, OK. The error message is finally suppressed by 2>/dev/null in this line.

[akinomyoga]

I think I need to withdraw this PR because it turned out that this is an issue specific to ble.sh (as far as command_not_found_handle checks COMP_CWORD), which attempts to call __load_completion outside the completion context (where COMP_CWORD is defined) to probe whether the completion is available.

This is still an issue when command_not_found_handle does not take account of COMP_CWORD, but I guess we do not receive the issue reports caused by such a command_not_found_handle recently.

[scop]

Cool. Reported https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1015215 for Debian, guess it'll trickle to various derivatives from there.