Bash's sadly flawed smart (programmable) completion
utcc.utoronto.ca
utcc.utoronto.ca
In contrast, bash almost always falls back to filename completion for the most common commands even when third party frameworks like bash-completion are installed. It's frustrating when I have to deal with interactive bash sessions because, sigh, Docker.
And when running a shell, do it like this:
docker run user/image:tag -it --rm bash -li
Also, zshdb, bashdb, and shellcheck are good stuff™ too.My mantra is all programs and widely-used company tools should have current man pages and shell completions. The whole "Go look at a web page" for "help" is slow, distracting, and lazy.
This one is so pathetically slow on Fedora that I find it counterproductive. Also, at least as of a year or two ago (I haven’t checked since then), PackageKit maintained its own, large, cache, thus wasting a surprising amount of space in /var.
Here's a naive, partial implementation that runs in <500 ms so long as there's an existing dnf cache:
command_not_found_handle() {
local pkgs
readarray pkgs < <(dnf rq --whatprovides "$1" -C --qf '%{name}\n' 2>/dev/null | sed '/^$/d' | sort -uVr)
if (( ! "${#pkgs[@]}" )); then
echo >&2 'Command not found and no package provides it according to the dnf cache'
return
fi
echo >&2 'Command not found, but offered via the following command(s):'
pkgs=("${pkgs[@]/#/ dnf install }")
echo >&2 " ${pkgs[@]}"
}This revolutionizes Bash's user experience.
I seem to recall doing an Arch installation a couple of years back and the zsh instance was well done but none of that setup was installed on the system even with zsh installed. I suppose I could have copied it from the installation media but didn't think about that at the time.
Didn't know about M-/ -- handy to have a solution that works on other people's systems.
"Meta" usually means "alt", except by default in macOS Terminal.app, where you need to go into the settings and check "alt is meta".