[TCLI-5] Optionally allow unkown options Created: 25/Oct/13 Updated: 28/Jun/16 Resolved: 02/Jan/14
|Reporter:||Hugo Duncan||Assignee:||Sung Pae|
When building a cli with subcommands, it can be useful to allow passing through unkown options as arguments, so they can be processed in a subcommand.
The current API doesn't allow for passing any configuration to the `cli` command, so this adds an `allow-unknown-opts?` var, which when bound to true, will pass through unknown options.
|Comment by Hugo Duncan [ 31/Oct/13 8:03 AM ]|
A patched version of tools.cli is available on clojars as `[com.palletops/tools.cli "0.2.4"]`
|Comment by Sung Pae [ 10/Dec/13 1:50 PM ]|
In the next version of tools.cli, parse-opts accepts an :in-order option to process arguments sequentially until the first unknown token.
The README has an explanation:
This is not the same as passing through unknown options, but it is the convention I am familiar with in large programs with subcommands.
Is this solution satisfactory for you?
The only times I have ever implemented a pass-through option for an options parser was for programs that wrap other command line programs. In these cases, the wrapper had a possibly intersecting superset of options, and I wanted to provide access to the underlying command's options without specifying them in my wrapper.
This worked okay, but the resulting options interface was complex, and since the relationship of the wrapper and underlying command was implicit, a bit fragile.
A major problem with the superset parser was that all unknown options were assumed to require arguments. This is necessary because it is impossible to tell whether `-ab` is meant to be interpreted as `-a -b` or `-a "b"` without knowing whether `-a` requires an argument. We can work around this by requiring that pass-through options always specify option arguments with an equal sign, but now we have introduced subtle differences for different tiers of options.
In contrast to all that, the subcommand options processing style of the git program and others like it allow many intersecting sets of options to be present in a single command invocation simply by following the easily understood convention:
cmd [cmd-opts] subcmd1 [subcmd1-opts] …
I hope you find this argument persuasive, but I am happy to discuss it further!
|Comment by Hugo Duncan [ 17/Dec/13 9:45 AM ]|
The new `:in-order` option provides a better solution.
|Comment by Sung Pae [ 02/Jan/14 1:36 AM ]|
Thank you for your thoughts on this.