-
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow the completed command to be an alias #1764
Comments
We are always open to PRs. I am not exactly good at the completion scripts. I couldn't even get zsh running locally 😞 |
My bash completion days are also behind me (and I happily flushed 90% I knew from memory). That being said, this patch seems to be doing the trick: --- src/completions/bash.rs
+++ src/completions/bash.rs
@@ -33,8 +33,8 @@ impl<'a, 'b> BashGen<'a, 'b> {
for i in ${{COMP_WORDS[@]}}
do
case "${{i}}" in
- {name})
- cmd="{name}"
+ "${{1}}")
+ cmd="${{1}}"
;;
{subcmds}
*)
@@ -43,7 +43,7 @@ impl<'a, 'b> BashGen<'a, 'b> {
done
case "${{cmd}}" in
- {name})
+ "${{1}}")
opts="{name_opts}"
if [[ ${{cur}} == -* || ${{COMP_CWORD}} -eq 1 ]] ; then
COMPREPLY=( $(compgen -W "${{opts}}" -- "${{cur}}") ) I'll probably open a PR unless I find an issue... |
I believe this is fixed. |
Mind sharing details as to why you believe that to be the case? |
@pickfire How is this fixed? |
This change adds support for generating a bash completion script. If sourced, the shell will provide tab completions for the program's arguments. There are two possible approaches provided by clap for going about generating shell completion functionality: either at build time by separately generating the clap parsers out-of-band or at run time, as an option to the main program itself. We are generally not too much in favor of a run time approach, as it means less inspectability at installation time and more overhead in the form of code crammed into the main binary. Hence, with this change we take the "build time" approach. Clap recommends hooking the generation up in build.rs, but this seems like an inflexible choice. For one, that is because it would mean unconditionally generating this file or some user-unfriendly environment variable based approach to making the process conditional. But also because specifying the command for which to generate the script should likely be configurable. That is a limitation of the completion script that clap generates (see clap-rs/clap#1764). Instead, we provide a utility program that emits the completion script to standard output, accepting regular command line options itself. In so doing we allow for installation time generation of the completion script or installation of the utility itself, the output of which could be sourced on demand -- depending on the user's preference.
This change adds support for generating a bash completion script. If sourced, the shell will provide tab completions for the program's arguments. There are two possible approaches provided by clap for going about generating shell completion functionality: either at build time, by separately generating the clap parsers out-of-band, or at run time, as an option to the main program itself. We are generally not too much in favor of a run time approach, as it means less inspectability at installation time and more overhead in the form of code crammed into the main binary. Hence, with this change we take the "build time" approach. Clap recommends hooking the generation up in build.rs, but this seems like an inflexible choice. For one, that is because it would mean unconditionally generating this file or using some user-unfriendly environment variable based approach for making the process conditional. But there is also the fact that specifying the command for which to generate the script should likely be configurable. That is a limitation of the completion script that clap generates (see clap-rs/clap#1764). In our version we provide a utility program that emits the completion script to standard output, accepting regular command line options itself. In doing so we allow for installation time generation of the completion script or installation of the utility itself, the output of which could be sourced on demand -- depending on the user's preference.
Because there was a pull request for it? Ah, I didn't notice it was closed instead of merged. |
This change adds support for generating a bash completion script. If sourced, the shell will provide tab completions for the program's arguments. There are two possible approaches provided by clap for going about generating shell completion functionality: either at build time, by separately generating the clap parsers out-of-band, or at run time, as an option to the main program itself. We are generally not too much in favor of a run time approach, as it means less inspectability at installation time and more overhead in the form of code crammed into the main binary. Hence, with this change we take the "build time" approach. Clap recommends hooking the generation up in build.rs, but this seems like an inflexible choice. For one, that is because it would mean unconditionally generating this file or using some user-unfriendly environment variable based approach for making the process conditional. But there is also the fact that specifying the command for which to generate the script should likely be configurable. That is a limitation of the completion script that clap generates (see clap-rs/clap#1764). In our version we provide a utility program that emits the completion script to standard output, accepting regular command line options itself. In doing so we allow for installation time generation of the completion script or installation of the utility itself, the output of which could be sourced on demand -- depending on the user's preference.
And it was closed without merging because it didn't actually fix the issue. |
This change adds support for generating a bash completion script. If sourced, the shell will provide tab completions for the program's arguments. There are two possible approaches provided by clap for going about generating shell completion functionality: either at build time, by separately generating the clap parsers out-of-band, or at run time, as an option to the main program itself. We are generally not too much in favor of a run time approach, as it means less inspectability at installation time and more overhead in the form of code crammed into the main binary. Hence, with this change we take the "build time" approach. Clap recommends hooking the generation up in build.rs, but this seems like an inflexible choice. For one, that is because it would mean unconditionally generating this file or using some user-unfriendly environment variable based approach for making the process conditional. But there is also the fact that specifying the command for which to generate the script should likely be configurable. That is a limitation of the completion script that clap generates (see clap-rs/clap#1764). In our version we provide a utility program that emits the completion script to standard output, accepting regular command line options itself. In doing so we allow for installation time generation of the completion script or installation of the utility itself, the output of which could be sourced on demand -- depending on the user's preference.
This change adds support for generating a bash completion script. If sourced, the shell will provide tab completions for the program's arguments. There are two possible approaches provided by clap for going about generating shell completion functionality: either at build time, by separately generating the clap parsers out-of-band, or at run time, as an option to the main program itself. We are generally not too much in favor of a run time approach, as it means less inspectability at installation time and more overhead in the form of code crammed into the main binary. Hence, with this change we take the "build time" approach. Clap recommends hooking the generation up in build.rs, but this seems like an inflexible choice. For one, that is because it would mean unconditionally generating this file or using some user-unfriendly environment variable based approach for making the process conditional. But there is also the fact that specifying the command for which to generate the script should likely be configurable. That is a limitation of the completion script that clap generates (see clap-rs/clap#1764). In our version we provide a utility program that emits the completion script to standard output, accepting regular command line options itself. In doing so we allow for installation time generation of the completion script or installation of the utility itself, the output of which could be sourced on demand -- depending on the user's preference.
This change adds support for generating a bash completion script. If sourced, the shell will provide tab completions for the program's arguments. There are two possible approaches provided by clap for going about generating shell completion functionality: either at build time, by separately generating the clap parsers out-of-band, or at run time, as an option to the main program itself. We are generally not too much in favor of a run time approach, as it means less inspectability at installation time and more overhead in the form of code crammed into the main binary. Hence, with this change we take the "build time" approach. Clap recommends hooking the generation up in build.rs, but this seems like an inflexible choice. For one, that is because it would mean unconditionally generating this file or using some user-unfriendly environment variable based approach for making the process conditional. But there is also the fact that specifying the command for which to generate the script should likely be configurable. That is a limitation of the completion script that clap generates (see clap-rs/clap#1764). In our version we provide a utility program that emits the completion script to standard output, accepting regular command line options itself. In doing so we allow for installation time generation of the completion script or installation of the utility itself, the output of which could be sourced on demand -- depending on the user's preference.
This change adds support for generating a bash completion script. If sourced, the shell will provide tab completions for the program's arguments. There are two possible approaches provided by clap for going about generating shell completion functionality: either at build time, by separately generating the clap parsers out-of-band, or at run time, as an option to the main program itself. We are generally not too much in favor of a run time approach, as it means less inspectability at installation time and more overhead in the form of code crammed into the main binary. Hence, with this change we take the "build time" approach. Clap recommends hooking the generation up in build.rs, but this seems like an inflexible choice. For one, that is because it would mean unconditionally generating this file or using some user-unfriendly environment variable based approach for making the process conditional. But there is also the fact that specifying the command for which to generate the script should likely be configurable. That is a limitation of the completion script that clap generates (see clap-rs/clap#1764). In our version we provide a utility program that emits the completion script to standard output, accepting regular command line options itself. In doing so we allow for installation time generation of the completion script or installation of the utility itself, the output of which could be sourced on demand -- depending on the user's preference.
This change adds support for generating a bash completion script. If sourced, the shell will provide tab completions for the program's arguments. There are two possible approaches provided by clap for going about generating shell completion functionality: either at build time by separately generating the clap parsers out-of-band or at run time, as an option to the main program itself. We are generally not too much in favor of a run time approach, as it means less inspectability at installation time and more overhead in the form of code crammed into the main binary. Hence, with this change we take the "build time" approach. Clap recommends hooking the generation up in build.rs, but this seems like an inflexible choice. For one, that is because it would mean unconditionally generating this file or some user unfriendly environment variable based approach to making the process conditional, but also because specifying the command for which to generate the script should likely be configurable. That is a limitation of the completion script that clap generates (see clap-rs/clap#1764). Instead, we provide a utility program that emits the completion script to standard output, accepting regular command line options itself.
This change adds support for generating a bash completion script. If sourced, the shell will provide tab completions for the program's arguments. There are two possible approaches provided by clap for going about generating shell completion functionality: either at build time by separately generating the clap parsers out-of-band or at run time, as an option to the main program itself. We are generally not too much in favor of a run time approach, as it means less inspectability at installation time and more overhead in the form of code crammed into the main binary. Hence, with this change we take the "build time" approach. Clap recommends hooking the generation up in build.rs, but this seems like an inflexible choice. For one, that is because it would mean unconditionally generating this file or some user unfriendly environment variable based approach to making the process conditional, but also because specifying the command for which to generate the script should likely be configurable. That is a limitation of the completion script that clap generates (see clap-rs/clap#1764). Instead, we provide a utility program that emits the completion script to standard output, accepting regular command line options itself.
This change adds support for generating a bash completion script. If sourced, the shell will provide tab completions for the program's arguments. There are two possible approaches provided by clap for going about generating shell completion functionality: either at build time by separately generating the clap parsers out-of-band or at run time, as an option to the main program itself. We are generally not too much in favor of a run time approach, as it means less inspectability at installation time and more overhead in the form of code crammed into the main binary. Hence, with this change we take the "build time" approach. Clap recommends hooking the generation up in build.rs, but this seems like an inflexible choice. For one, that is because it would mean unconditionally generating this file or some user unfriendly environment variable based approach to making the process conditional, but also because specifying the command for which to generate the script should likely be configurable. That is a limitation of the completion script that clap generates (see clap-rs/clap#1764). Instead, we provide a utility program that emits the completion script to standard output, accepting regular command line options itself.
This change adds support for generating a bash completion script. If sourced, the shell will provide tab completions for the program's arguments. There are two possible approaches provided by clap for going about generating shell completion functionality: either at build time by separately generating the clap parsers out-of-band or at run time, as an option to the main program itself. We are generally not too much in favor of a run time approach, as it means less inspectability at installation time and more overhead in the form of code crammed into the main binary. Hence, with this change we take the "build time" approach. Clap recommends hooking the generation up in build.rs, but this seems like an inflexible choice. For one, that is because it would mean unconditionally generating this file or some user unfriendly environment variable based approach to making the process conditional, but also because specifying the command for which to generate the script should likely be configurable. That is a limitation of the completion script that clap generates (see clap-rs/clap#1764). Instead, we provide a utility program that emits the completion script to standard output, accepting regular command line options itself.
This change adds support for generating shell completion scripts for the program. If sourced, the shell will provide tab completions for the program's arguments. There are two possible approaches provided by clap for going about generating shell completion functionality: either at build time by separately generating the clap parsers out-of-band or at run time, as an option to the main program itself. We are generally not too much in favor of a run time approach, as it means less inspectability at installation time and more overhead in the form of code crammed into the main binary. Hence, with this change we take the "build time" approach. Clap recommends hooking the generation up in build.rs, but this seems like an inflexible choice. For one, that is because it would mean unconditionally generating this file or some user unfriendly environment variable based approach to making the process conditional, but also because specifying the command for which to generate the script should likely be configurable. That is a limitation of the completion script that clap generates (see clap-rs/clap#1764). Instead, we provide a utility program that emits the completion script to standard output, accepting regular command line options itself.
This change adds support for generating shell completion scripts for the program. If sourced, the shell will provide tab completions for the program's arguments. There are two possible approaches provided by clap for going about generating shell completion functionality: either at build time by separately generating the clap parsers out-of-band or at run time, as an option to the main program itself. We are generally not too much in favor of a run time approach, as it means less inspectability at installation time and more overhead in the form of code crammed into the main binary. Hence, with this change we take the "build time" approach. Clap recommends hooking the generation up in build.rs, but this seems like an inflexible choice. For one, that is because it would mean unconditionally generating this file or some user unfriendly environment variable based approach to making the process conditional, but also because specifying the command for which to generate the script should likely be configurable. That is a limitation of the completion script that clap generates (see clap-rs/clap#1764). Instead, we provide a utility program that emits the completion script to standard output, accepting regular command line options itself.
It would be great if the shell completion was more flexible in what commands it applies to. Let's say I have a program
foo
and a completion scriptfoo.bash
as generated byclap
. If I sourcefoo.bash
I now have completion forfoo
's arguments. Fine.However, what if I have aliased
f
tofoo
? Naturally, I'd want to have completion forf
as well. Usually that's not a problem. The completion script just registers the completion functionality for a certain command. E.g.,complete -F _foo -o bashdefault -o default foo
can be found in
foo.bash
.Unfortunately, though, just changing that to
complete -F _foo -o bashdefault -o default f
doesn't work, because, well, the script itself has the command/name coded into its logic.
That doesn't have to be the case, however, as
git
for example shows. Here all I have to do is register my alias as follows:and bam,
g
has completion.Would be great to have such a more flexible completion script.
The text was updated successfully, but these errors were encountered: