bash-completion
bash-completion copied to clipboard
scop
adding an alias completion helper
Hey there.
A recurring question seems to be how to automatically get completions for aliases. Numerous code snippets and helper functions can be found, e.g. here:
- https://stackoverflow.com/questions/342969/how-do-i-get-bash-completion-to-work-with-aliases
- https://unix.stackexchange.com/questions/4219/how-do-i-get-bash-completion-for-command-aliases
- https://superuser.com/questions/436314/how-can-i-get-bash-to-perform-tab-completion-for-my-aliases
- https://ubuntuforums.org/showthread.php?t=733397
- https://unix.stackexchange.com/questions/216748/how-to-re-use-existing-completion-with-recent-bash-completion
- https://github.com/cykerway/complete-alias/blob/master/complete_alias
It seems that getting it right and especially covering all cases, like support for git or to get aliases completed that already contained arguments, is trickier than a one liner.
I think it would be nice if bash-completion could provide a proper helper for this, i.e. one that covers all cases and solves it reasonably cleanly. Shipping this with bash-completion would have the great benefit, that sooner or later most distros would get it out-of-the box, while a separate small project has often only little chances to really find its way into all distros.
Cheers, Chris.
I can have a look if someone submits one, however if it doesn't come with a promise to help maintain it (well to take ownership to be fair), it needs to be one that doesn't make my head hurt (and come with a bunch of test cases). I'm afraid the ones quickly visible from the links all do inflict that ache.
Failing that, I could add a FAQ entry for this and point towards https://github.com/cykerway/complete-alias, that one seems a cleanly installable thing that works for all cases if it works as advertised. But I'd need to take a closer look at it before doing so.
Should I ask the maintainer of complete-alias whether he'd consider to merge it into bash-completion?
If the test cases and offer for long term maintainership within bash-completion are in order, sure.
I think a FAQ entry is good for now, and take your time to review complete-alias if you are interested in merging.
Nice... how does it come that this seems so much smaller in terms of of code than cykerway/complete-alias?
#104 is the version 7 years before. I just today realized that @cykerway has already submitted the very initial version of cykerway/complete-alias in bash-completion as a PR, so I thought it'd be good to mention it for reference.
No one has yet started to work on the migration of the latest version of complete-alias to bash-completion, but if it would finally be merged, it should replace #104 (or we might work on it by adding commits in #104, but I haven't checked in detail how much the latest version has been changed since #104).
I found that bash has a progcomp_alias shopt that is close to doing the desired behavior of expanding aliases for completions, but it is only used as a last resort if complete -D is not active which makes it incompatible with dynamically loaded completions. If the relative priorities could be flipped around I believe that would solve everything and architecturally that seems much cleaner than a reimplementation of alias parsing and expansion in shell functions. It seems like this idea has been raised at least once in the past but not met with much enthusiasm.
One workaround I have been using is to simply expand the alias manually before attempting to trigger completion. By default bash binds the key chord Alt-Control-e to the command shell-expand-line, which will expand the alias. It will also expand any $variables in the input line so if so if this is not desirable one may prefer a binding to the alias-expand-line command instead.
I remember there were similar discussions about complete -D and progcomp_alias in the past. FWIW, these are the discussions that I can find now:
- https://github.com/ohmybash/oh-my-bash/pull/380#issuecomment-1347397860
- https://github.com/scop/bash-completion/issues/383#issue-552422716