3 ms·

> It's rare for bash to complete anything but filenames. zsh gives me subcommands and flags with descriptions. I think that hasn't been true for a very long ti

> It's rare for bash to complete anything but filenames. zsh gives me subcommands and flags with descriptions. I think that hasn't been true for a very long time, although it might be that I'm biased because I've been installing the "bash completion" package alongside bash on all my systems. (In my case "apt-get install bash-completion".) bash typically completes commands, sub-commands, flags, and file/directory names for me. It is also common for new tools to ship with bash-completion support, often missing support for other shells.

soraminazuki 3y ago
I have tried bash-completion and it doesn't make much of a difference. It's already underwhelming that bash requires third party completion frameworks to get completion working beyond command names, variable names, and filenames. But even with bash-completion, completion for the most common commands are either missing or incomplete. Take grep, for example. I only get --binary-files, --context, and --null. That's only three out of a few dozen options. Or tar, which only shows c, t, and x. For ls, probably the most frequently used command, only --color and --help. Git requires another third party completion framework. Unfortunately, those are the best case examples. For other commands like vim or emacs, option completion is missing. The same even goes for bash builtins. And don't get me started on completion behavior. Though I will say the lack of descriptions for each option takes away half the usefulness of shell completion. zsh can actually use completion functions written for bash. But I never felt the need.
- stevekemp 3y ago
  Your reply suprises me, when I run "grep --[TAB]" I go a whole bunch of flags. I'd probably suggest that bash-completion being a "third party" package is a good thing, it's entirely external to the bash project and that's good. It means we're not pinned to releases alongside the shell. After all it has support for ssh, grep, and many more tools they should be able to contribute to one location and the shell-project itself would be thee wrong one. bash completion provides a framework for adding completion to "stuff", and the git-package on Debian uses that to drop a file into `/usr/share/bash-completion/completions/` so there's no need for any other third party framework: 1. Install git 2. Install bash completion package 3. Everything should just work. Anyway I guess a lot of this will depend on the system you're using, and how their packages are configured, but I don't personally believe that bash completion is in a terrible state.

soraminazuki 3y ago

I have tried bash-completion and it doesn't make much of a difference. It's already underwhelming that bash requires third party completion frameworks to get completion working beyond command names, variable names, and filenames. But even with bash-completion, completion for the most common commands are either missing or incomplete. Take grep, for example. I only get --binary-files, --context, and --null. That's only three out of a few dozen options. Or tar, which only shows c, t, and x. For ls, probably the most frequently used command, only --color and --help. Git requires another third party completion framework. Unfortunately, those are the best case examples. For other commands like vim or emacs, option completion is missing. The same even goes for bash builtins. And don't get me started on completion behavior. Though I will say the lack of descriptions for each option takes away half the usefulness of shell completion. zsh can actually use completion functions written for bash. But I never felt the need.

stevekemp 3y ago
Your reply suprises me, when I run "grep --[TAB]" I go a whole bunch of flags. I'd probably suggest that bash-completion being a "third party" package is a good thing, it's entirely external to the bash project and that's good. It means we're not pinned to releases alongside the shell. After all it has support for ssh, grep, and many more tools they should be able to contribute to one location and the shell-project itself would be thee wrong one. bash completion provides a framework for adding completion to "stuff", and the git-package on Debian uses that to drop a file into `/usr/share/bash-completion/completions/` so there's no need for any other third party framework: 1. Install git 2. Install bash completion package 3. Everything should just work. Anyway I guess a lot of this will depend on the system you're using, and how their packages are configured, but I don't personally believe that bash completion is in a terrible state.