Improve support for command aliases #292
Comments
martinvonz
added a commit
that referenced
this issue
May 8, 2022
By having the global arguments on a separate struct, I think it will be easier to improve how we resolve aliases (#292).
martinvonz
added a commit
that referenced
this issue
May 8, 2022
By having the global arguments on a separate struct, I think it will be easier to improve how we resolve aliases (#292).
martinvonz
added a commit
that referenced
this issue
May 9, 2022
Our support for aliases is very naively implemented; it assumes the alias is the first argument in argv. It therefore fails to resolve aliases after global arguments such as `--at-op`. This patch fixes that by using doing an intial parse of the arguments with a modified definition of the CLI passed to `clap`. The modified definition has only global arguments, plus an "external subcommand". That way we can convince `clap` to parse the global arguments for us and give us the alias (or real command) and further arguments back. Thanks to @epage for the suggestion on in clap-rs/clap#3672. The only minor problem is that it doesn't seem possible to tell `clap` to parse global arguments that come after the external subcommand. To work around that, we manually merge any parsed global argument before the alias with any parsed global arguments after it. Closes #292.
martinvonz
added a commit
that referenced
this issue
May 9, 2022
Our support for aliases is very naively implemented; it assumes the alias is the first argument in argv. It therefore fails to resolve aliases after global arguments such as `--at-op`. This patch fixes that by modifying the command defintion to have an "external subcommand" in the list of available commands. That make `clap` give us the remainder of the arguments when it runs into an unknown command. The first in the list will then be an alias or simply an unknown command. Thanks to @epage for the suggestion on in clap-rs/clap#3672. The only minor problem is that it doesn't seem possible to tell `clap` to parse global arguments that come after the external subcommand. To work around that, we manually merge any parsed global argument before the alias with any parsed global arguments after it. With the new structure, it was easy to handle recursive alias definitions, so I added support for that too. Closes #292.
martinvonz
added a commit
that referenced
this issue
May 9, 2022
Our support for aliases is very naively implemented; it assumes the alias is the first argument in argv. It therefore fails to resolve aliases after global arguments such as `--at-op`. This patch fixes that by modifying the command defintion to have an "external subcommand" in the list of available commands. That make `clap` give us the remainder of the arguments when it runs into an unknown command. The first in the list will then be an alias or simply an unknown command. Thanks to @epage for the suggestion on in clap-rs/clap#3672. The only minor problem is that it doesn't seem possible to tell `clap` to parse global arguments that come after the external subcommand. To work around that, we manually merge any parsed global argument before the alias with any parsed global arguments after it. With the new structure, it was easy to handle recursive alias definitions, so I added support for that too. Closes #292.
martinvonz
added a commit
that referenced
this issue
May 9, 2022
Our support for aliases is very naively implemented; it assumes the alias is the first argument in argv. It therefore fails to resolve aliases after global arguments such as `--at-op`. This patch fixes that by modifying the command defintion to have an "external subcommand" in the list of available commands. That make `clap` give us the remainder of the arguments when it runs into an unknown command. The first in the list will then be an alias or simply an unknown command. Thanks to @epage for the suggestion on in clap-rs/clap#3672. The only minor problem is that it doesn't seem possible to tell `clap` to parse global arguments that come after the external subcommand. To work around that, we manually merge any parsed global argument before the alias with any parsed global arguments after it. With the new structure, it was easy to handle recursive alias definitions, so I added support for that too. Closes #292.
martinvonz
added a commit
that referenced
this issue
May 10, 2022
Our support for aliases is very naively implemented; it assumes the alias is the first argument in argv. It therefore fails to resolve aliases after global arguments such as `--at-op`. This patch fixes that by modifying the command defintion to have an "external subcommand" in the list of available commands. That make `clap` give us the remainder of the arguments when it runs into an unknown command. The first in the list will then be an alias or simply an unknown command. Thanks to @epage for the suggestion on in clap-rs/clap#3672. The only minor problem is that it doesn't seem possible to tell `clap` to parse global arguments that come after the external subcommand. To work around that, we manually merge any parsed global argument before the alias with any parsed global arguments after it. With the new structure, it was easy to handle recursive alias definitions, so I added support for that too. Closes #292.
martinvonz
added a commit
that referenced
this issue
May 10, 2022
By having the global arguments on a separate struct, I think it will be easier to improve how we resolve aliases (#292).
martinvonz
added a commit
that referenced
this issue
May 10, 2022
Our support for aliases is very naively implemented; it assumes the alias is the first argument in argv. It therefore fails to resolve aliases after global arguments such as `--at-op`. This patch fixes that by modifying the command defintion to have an "external subcommand" in the list of available commands. That make `clap` give us the remainder of the arguments when it runs into an unknown command. The first in the list will then be an alias or simply an unknown command. Thanks to @epage for the suggestion on in clap-rs/clap#3672. The only minor problem is that it doesn't seem possible to tell `clap` to parse global arguments that come after the external subcommand. To work around that, we manually merge any parsed global argument before the alias with any parsed global arguments after it. With the new structure, it was easy to handle recursive alias definitions, so I added support for that too. Closes #292.
martinvonz
added a commit
that referenced
this issue
May 11, 2022
Our support for aliases is very naively implemented; it assumes the alias is the first argument in argv. It therefore fails to resolve aliases after global arguments such as `--at-op`. This patch fixes that by modifying the command defintion to have an "external subcommand" in the list of available commands. That make `clap` give us the remainder of the arguments when it runs into an unknown command. The first in the list will then be an alias or simply an unknown command. Thanks to @epage for the suggestion on in clap-rs/clap#3672. The only minor problem is that it doesn't seem possible to tell `clap` to parse global arguments that come after the external subcommand. To work around that, we manually merge any parsed global argument before the alias with any parsed global arguments after it. With the new structure, it was easy to handle recursive alias definitions, so I added support for that too. Closes #292.
martinvonz
added a commit
that referenced
this issue
May 11, 2022
Our support for aliases is very naively implemented; it assumes the alias is the first argument in argv. It therefore fails to resolve aliases after global arguments such as `--at-op`. This patch fixes that by modifying the command defintion to have an "external subcommand" in the list of available commands. That make `clap` give us the remainder of the arguments when it runs into an unknown command. The first in the list will then be an alias or simply an unknown command. Thanks to @epage for the suggestion on in clap-rs/clap#3672. The only minor problem is that it doesn't seem possible to tell `clap` to parse global arguments that come after the external subcommand. To work around that, we manually merge any parsed global argument before the alias with any parsed global arguments after it. With the new structure, it was easy to handle recursive alias definitions, so I added support for that too. Closes #292.
martinvonz
added a commit
that referenced
this issue
May 11, 2022
Our support for aliases is very naively implemented; it assumes the alias is the first argument in argv. It therefore fails to resolve aliases after global arguments such as `--at-op`. This patch fixes that by modifying the command defintion to have an "external subcommand" in the list of available commands. That makes `clap` give us the remainder of the arguments when it runs into an unknown command. The first in the list will then be an alias or simply an unknown command. Thanks to @epage for the suggestion on in clap-rs/clap#3672. With the new structure, it was easy to handle recursive alias definitions, so I added support for that too. Closes #292.
martinvonz
added a commit
that referenced
this issue
May 12, 2022
Our support for aliases is very naively implemented; it assumes the alias is the first argument in argv. It therefore fails to resolve aliases after global arguments such as `--at-op`. This patch fixes that by modifying the command defintion to have an "external subcommand" in the list of available commands. That makes `clap` give us the remainder of the arguments when it runs into an unknown command. The first in the list will then be an alias or simply an unknown command. Thanks to @epage for the suggestion on in clap-rs/clap#3672. With the new structure, it was easy to handle recursive alias definitions, so I added support for that too. Closes #292.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Description
Our support for aliases is currently very naive. It doesn't allow global flags after the alias. We should be able to improve that by mimicking what cargo does. Thanks to @epage for the hints.
Specifications
The text was updated successfully, but these errors were encountered: