News for hackers. Stuff that matters.
Re:Bash's sadly flawed smart (programmable) completion by soraminazuki on Wednesday April 10, 2024 @12:40PM (#39992734)
I wonder what the author thinks of zsh. Unlike bash, zsh completion just works. It's context-aware, properly completes subcommands and options, and doesn't suffer from the problem explained in the article. It even shows descriptions for each of the completion candidates.

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.

Re:Bash's sadly flawed smart (programmable) completion by siproprio on Wednesday April 10, 2024 @09:25PM (#39997506)
yeah, zsh is just superior. it can even emulate bash!
Re:Bash's sadly flawed smart (programmable) completion by throwiforgtnlzy on Friday April 12, 2024 @01:20AM (#40009601)
Yes. 15+ year zsh user here. When dealing with bash, try to sneak in PackageKit-command-not-found and bash-completion.

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.

Re:Bash's sadly flawed smart (programmable) completion by amluto on Friday April 12, 2024 @09:14AM (#40012326)
> PackageKit-command-not-found

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.

Re:Bash's sadly flawed smart (programmable) completion by throwiforgtnlzy on Friday April 12, 2024 @09:47PM (#40019677)
It depends. It's better than nothing that can be ^C'ed.

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[@]}"
  }