7 ms·

I always disable shell completion after it burned me a few times: 1. Completion that blocks the shell, by doing a lookup across a network (e.g. to complete a r

by nfoz 7y ago

I always disable shell completion after it burned me a few times: 1. Completion that blocks the shell, by doing a lookup across a network (e.g. to complete a remote path). Can hang for several seconds. 2. Completion that gives me a misleading/incorrect view of the filesystem, by "intelligently" filtering which files/filetypes it will let me complete. For example, if I have foo.mp3 and foo.txt, and a media-player command tab-completes and only "sees" the mp3, but I actually wanted to know that the .txt was there as well (and in some cases, open it with the media player!) 3. When the completion has a wrong view of the options provided by a program (e.g. completion is not aware of some useful options). Instead of looking at the man-page, I've been tricked by a bad completion-set. I would love a better shell with good completion, but I need to avoid these types of problems. Does anyone else run into this?

gpderetta 7y ago
I've run into all of these, but, FWIW, I still prefer smart autocompletion in bash by a large margin. Somehow I learned to avoid the bad areas I guess.
roryrjb 7y ago
Some of this could be down to the completions that are provided. A package such as bash-completions comes with completions for a lot of common software. One specific solution to your problem, well a suggestion is to use oksh (https://github.com/ibara/oksh https://github.com/ibara/oksh) a portable version of pdksh (public domain Korn shell) that comes from OpenBSD. The reason why I recommend this shell is that it has programmable completion, although it is much simpler than what's provided by bash and that aside from the built in file name completion it won't come with anything else and you won't find (aside from people's dotfiles on Github) any packages that provide you with anything. Basically you have to customise it to your needs, but because the completion is so simple, whenever you find yourself in a situation where you'd want completion, spend a few minutes adding it to your .kshrc and move on.
hnlmorg 7y ago
Coincidentally just this week I've working to resolve point 1 in my own shell (https://github.com/lmorg/murex https://github.com/lmorg/murex). The compromise I came up with was: - The shell would attempt to return all suggestions immediately - However a subset of functions which are known to be slower queries (like recursive directory look ups on larger file system hierarchies) are given a "soft timeout" -- where after that timeout is reached, the slower faster subset of functions are returned as the suggestions while the slower subset continues to run in the background - The slower subset are also given a "hard timeout" where when that point is reached, if the function still hasn't completed then it is just killed. Any results is has produced (if any) by that point are appended to the auto-completion suggestions. - If the slower subset finished before the hard timeout then it is appended to the suggestions. If it finishes before the soft timeout then it's just part of the suggestions. At the moment it's only been implemented for file and directory suggestions. The fast function is just any files and directories in the current directory level; where as the slow function will return a larger directory hierarchy (for quick navigating akin to fzf). But the plan is to extend it further to support other dynamic completers as well. This wouldn't completely solve your point though. If the "fast" query actually runs slow (eg you're trying to complete when inside a network mounted filesystem when the network is dropping) then the shell would still hang. At some point I'll add timeouts on them as well. But I am inching towards that goal. Be warned though, because this feature is less than a week old, it's still only in a feature branch. :) Your point on 3 is apt too. One of the things I built early on was man page parsing for auto-completion suggestions. I've since learned that I'm not alone in that regard either (Fish does it as well -- and from some of the demo's I've watched it looks like they've done a nicer job there too). More recently I've also been writing tools that parse binaries for flags as well (in instances where you download a statically compiled binary - eg terraform - and thus don't have any corresponding man pages). That work is very much in it's infancy though.
jolmg 7y ago
> 1. Completion that blocks the shell, by doing a lookup across a network (e.g. to complete a remote path). Can hang for several seconds. I've had this happen to me. Would be nice if it could be interrupted with Ctrl-C. My workaround has been to wrap the argument that's triggering that in quotes (when redoing the command in another terminal). > 2. Completion that gives me a misleading/incorrect view of the filesystem, by "intelligently" filtering which files/filetypes it will let me complete. For example, if I have foo.mp3 and foo.txt, and a media-player command tab-completes and only "sees" the mp3, but I actually wanted to know that the .txt was there as well (and in some cases, open it with the media player!) Maybe a keybinding can be added to enable/disable "smart" completion (leaving only simple filepath completion). Seems like it should be a relatively quick configuration fix. My workaround for this, for when I want simple filepath completion, has been to prefix the command with `echo`. With vi keybindings it's just `<Esc>Iecho <Esc>A` (it's faster if you make your CapsLock an Esc); with emacs keybindings it's `<Ctrl-A>echo <Ctrl-E>`. Afterwards, to delete the `echo`, it's `<Esc>^dwA` with vi keybindings and `<Ctrl-A><Alt-D><Ctrl-D><Ctrl-E>` with emacs keybindings. > 3. When the completion has a wrong view of the options provided by a program (e.g. completion is not aware of some useful options). Instead of looking at the man-page, I've been tricked by a bad completion-set. Maybe the list of options could be parsed out of manpages and --help output. Then, it would coincide.
- hddqsb 7y ago
  > Maybe a keybinding can be added to enable/disable "smart" completion (leaving only simple filepath completion). Seems like it should be a relatively quick configuration fix. There is a keybinding to do simple filename completion: Alt-/ (https://www.gnu.org/software/bash/manual/bash.html#index-complete_002dfilename-_0028M_002d_002f_0029 https://www.gnu.org/software/bash/manual/bash.html#index-com...).
- earenndil 7y ago
  At least in zsh, you can interrupt slow autocompletes with ^C.
  - opk 7y ago
    Zsh also lets you configure, via the `remote-access` style whether you want to allow it to make remote connections for completion to begin with.
ciupicri 7y ago
Regarding (2), I hate the completion for fdisk [1]. It filters device filenames starting with /dev/disk/{by-id,by-path} even if those names make it easy to select a particular disk. [1]: https://github.com/karelzak/util-linux/blob/master/bash-completion/fdisk https://github.com/karelzak/util-linux/blob/master/bash-comp...
giancarlostoro 7y ago
I use Fish for that kind of thing. I dont write shell scripts for Fish thats what I use Bash for (portability) but Fish has intelligent auto complete hints.
SPBS 7y ago
Yeah homebrew does that remote lookup thing when I try to complete `brew install xx<TAB>`. Because of the delay, it's not a good way to discover packages at all especially if the package name has an unexpected prefix that causes bash completion to fail. Much better to just `brew search xx` then browse the entire list of possible candidates than to rely on tab completion.
- pcr910303 7y ago
  > Yeah homebrew does that remote lookup thing when I try to complete `brew install xx<TAB>`. AFAIK Homebrew doesn't do remote lookup, you can try it out by turning off your Wi-Fi & autocompleting formula names still work. > Because of the delay, it's not a good way to discover packages at all The delay is due to ruby's slow speed, it looks like home-brew just searches the whole formula directory with ruby.
bobbylarrybobby 7y ago
Fish shell?
JoshTriplett 7y ago
Regarding 3: I wish that all completions were provided by the programs (ideally by invoking the program) rather than by a hard-coded list in a bash-completion file.
- arianvanp 7y ago
  In haskell the parser library for your cli auto-generated a completion file which is very convenient.

by nfoz 7y ago

gpderetta 7y ago

I've run into all of these, but, FWIW, I still prefer smart autocompletion in bash by a large margin. Somehow I learned to avoid the bad areas I guess.

roryrjb 7y ago

Some of this could be down to the completions that are provided. A package such as bash-completions comes with completions for a lot of common software. One specific solution to your problem, well a suggestion is to use oksh (https://github.com/ibara/oksh https://github.com/ibara/oksh) a portable version of pdksh (public domain Korn shell) that comes from OpenBSD. The reason why I recommend this shell is that it has programmable completion, although it is much simpler than what's provided by bash and that aside from the built in file name completion it won't come with anything else and you won't find (aside from people's dotfiles on Github) any packages that provide you with anything. Basically you have to customise it to your needs, but because the completion is so simple, whenever you find yourself in a situation where you'd want completion, spend a few minutes adding it to your .kshrc and move on.

hnlmorg 7y ago

Coincidentally just this week I've working to resolve point 1 in my own shell (https://github.com/lmorg/murex https://github.com/lmorg/murex). The compromise I came up with was: - The shell would attempt to return all suggestions immediately - However a subset of functions which are known to be slower queries (like recursive directory look ups on larger file system hierarchies) are given a "soft timeout" -- where after that timeout is reached, the slower faster subset of functions are returned as the suggestions while the slower subset continues to run in the background - The slower subset are also given a "hard timeout" where when that point is reached, if the function still hasn't completed then it is just killed. Any results is has produced (if any) by that point are appended to the auto-completion suggestions. - If the slower subset finished before the hard timeout then it is appended to the suggestions. If it finishes before the soft timeout then it's just part of the suggestions. At the moment it's only been implemented for file and directory suggestions. The fast function is just any files and directories in the current directory level; where as the slow function will return a larger directory hierarchy (for quick navigating akin to fzf). But the plan is to extend it further to support other dynamic completers as well. This wouldn't completely solve your point though. If the "fast" query actually runs slow (eg you're trying to complete when inside a network mounted filesystem when the network is dropping) then the shell would still hang. At some point I'll add timeouts on them as well. But I am inching towards that goal. Be warned though, because this feature is less than a week old, it's still only in a feature branch. :) Your point on 3 is apt too. One of the things I built early on was man page parsing for auto-completion suggestions. I've since learned that I'm not alone in that regard either (Fish does it as well -- and from some of the demo's I've watched it looks like they've done a nicer job there too). More recently I've also been writing tools that parse binaries for flags as well (in instances where you download a statically compiled binary - eg terraform - and thus don't have any corresponding man pages). That work is very much in it's infancy though.

jolmg 7y ago

> 1. Completion that blocks the shell, by doing a lookup across a network (e.g. to complete a remote path). Can hang for several seconds. I've had this happen to me. Would be nice if it could be interrupted with Ctrl-C. My workaround has been to wrap the argument that's triggering that in quotes (when redoing the command in another terminal). > 2. Completion that gives me a misleading/incorrect view of the filesystem, by "intelligently" filtering which files/filetypes it will let me complete. For example, if I have foo.mp3 and foo.txt, and a media-player command tab-completes and only "sees" the mp3, but I actually wanted to know that the .txt was there as well (and in some cases, open it with the media player!) Maybe a keybinding can be added to enable/disable "smart" completion (leaving only simple filepath completion). Seems like it should be a relatively quick configuration fix. My workaround for this, for when I want simple filepath completion, has been to prefix the command with `echo`. With vi keybindings it's just `<Esc>Iecho <Esc>A` (it's faster if you make your CapsLock an Esc); with emacs keybindings it's `<Ctrl-A>echo <Ctrl-E>`. Afterwards, to delete the `echo`, it's `<Esc>^dwA` with vi keybindings and `<Ctrl-A><Alt-D><Ctrl-D><Ctrl-E>` with emacs keybindings. > 3. When the completion has a wrong view of the options provided by a program (e.g. completion is not aware of some useful options). Instead of looking at the man-page, I've been tricked by a bad completion-set. Maybe the list of options could be parsed out of manpages and --help output. Then, it would coincide.

hddqsb 7y ago
> Maybe a keybinding can be added to enable/disable "smart" completion (leaving only simple filepath completion). Seems like it should be a relatively quick configuration fix. There is a keybinding to do simple filename completion: Alt-/ (https://www.gnu.org/software/bash/manual/bash.html#index-complete_002dfilename-_0028M_002d_002f_0029 https://www.gnu.org/software/bash/manual/bash.html#index-com...).
earenndil 7y ago
At least in zsh, you can interrupt slow autocompletes with ^C.
- opk 7y ago
  Zsh also lets you configure, via the `remote-access` style whether you want to allow it to make remote connections for completion to begin with.

ciupicri 7y ago

Regarding (2), I hate the completion for fdisk [1]. It filters device filenames starting with /dev/disk/{by-id,by-path} even if those names make it easy to select a particular disk. [1]: https://github.com/karelzak/util-linux/blob/master/bash-completion/fdisk https://github.com/karelzak/util-linux/blob/master/bash-comp...

giancarlostoro 7y ago

I use Fish for that kind of thing. I dont write shell scripts for Fish thats what I use Bash for (portability) but Fish has intelligent auto complete hints.

SPBS 7y ago

Yeah homebrew does that remote lookup thing when I try to complete `brew install xx<TAB>`. Because of the delay, it's not a good way to discover packages at all especially if the package name has an unexpected prefix that causes bash completion to fail. Much better to just `brew search xx` then browse the entire list of possible candidates than to rely on tab completion.

pcr910303 7y ago
> Yeah homebrew does that remote lookup thing when I try to complete `brew install xx<TAB>`. AFAIK Homebrew doesn't do remote lookup, you can try it out by turning off your Wi-Fi & autocompleting formula names still work. > Because of the delay, it's not a good way to discover packages at all The delay is due to ruby's slow speed, it looks like home-brew just searches the whole formula directory with ruby.

bobbylarrybobby 7y ago

Fish shell?

JoshTriplett 7y ago

Regarding 3: I wish that all completions were provided by the programs (ideally by invoking the program) rather than by a hard-coded list in a bash-completion file.

arianvanp 7y ago
In haskell the parser library for your cli auto-generated a completion file which is very convenient.