-
-
Notifications
You must be signed in to change notification settings - Fork 1.7k
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
Add documentation on tricks and traps of using optional options #1332
Changes from 2 commits
94b7f1b
0588e30
3f8623e
5746704
9812ee7
c686ee3
3e29566
5a2b953
53cf35b
8113f41
3434f4d
0b5f249
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,78 @@ | ||
# Tricks and traps when using options with optional values | ||
|
||
There are potential challenges using options with optional values. They seem quite attractive and the README used to use them more than options with require values but in practice, they are a bit tricky and aren't a free choice. | ||
|
||
## Parsing ambiguity | ||
|
||
There is parsing ambiguity when using option as boolean flag and also having it accept operands and subcommands. | ||
|
||
``` | ||
program.command('example') | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I suggest change the example to taking an argument, and no subcommands. I think that will be the common problem case, whether it is a single level command, or down in a subcommand. Also, I would like it to look like it does something. My boring description you worked from was `example -o optionalValue' but it is more fun when the program looks more interesting. I struggle to come up with nice examples! For this section we just need one optional value and one optional argument, so the command should make sense with one, or the other, or both. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Oh what is the difference between optional value and optional argument? I though they are the same thing There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Oops, that raises another thing I had been thinking about: terminology! When I wrote "optional argument" I was intending to mean a non-option argument, sometimes called an "operand" or "positional argument". I am not very familiar with either term, and wonder whether "non-option argument" is simple and clear. What I meant was a non-option argument, like:
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'll dump some research on terminology in here for reference. I haven't decided what terms to recommend yet! A number of sources use "positional" as a qualifier, which I assume is meaning in particular that the order matters. https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap12.html https://docs.python.org/3/library/argparse.html yargs https://oclif.io/docs https://github.com/spf13/cobra#concepts There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. okay, I understand the term you are referring to now. I added a terminology section explaining only the terms used in this document. I usually clump the terms together if they mean about the same thing. This is good if we come from different backgrounds because we would have something easy to cross-reference to. I also add a new terminology if I find myself giving it an alias; in this case the borrowed alias "optional options" though I'm not sure if the terminology is well explained There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. If we get the terms nice and clean, I'll be updating the README to be more consistent! I have been trying hard to be clear there, but I haven't got it consistent yet. Mentioning terms used in other places is potentially useful, but I don't want "our" terms and "other" terms just listed mixed together. Perhaps, "sometimes called", like:
I do not see "operand" used very much apart from the Open Group, and currently considering "command argument" to match up quite nicely with I had been trying to reduce use of "argument" because seemed different before and after parsing, but maybe qualifying could work. So there are CLI arguments before parsing (e.g. |
||
.option("-o, --option [optionalValue]") | ||
.command('brew') | ||
.action(() => { | ||
console.log("example brew"); | ||
}) | ||
|
||
program.parse(process.argv); | ||
|
||
if (program.option) console.log(`option: ${program.option}`); | ||
``` | ||
|
||
``` | ||
$ example -o | ||
option: true | ||
$ example -o thisValueIsPassedToOption | ||
option: thisValueIsPassedToOption | ||
$ example -o brew | ||
option: brew | ||
$ example -o nextArg | ||
option: nextArg | ||
``` | ||
|
||
For example, you may intend `brew` to be passed as a subcommand. Instead, it will be read as the passed in value for `-o`. Likewise, you may intend `nextArg` to be passed as an argument but it too, will be read as the passed in value for `-o` | ||
|
||
### Possible workarounds | ||
|
||
To reduce such ambiguity, you can do the following: | ||
|
||
1. always use `--` before operands | ||
2. add your options after operands | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. After reading the terminology, I realise this is wrong. Shouldn't it be "add your options before operands" ? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The posix convention is that options always come before operands. The GNU utility convention allows options to come before or after the operands. Commander follows the GNU convention and allows options before or after the operands. So by putting the options last, the option values do not get confused with the operands. So instead of writing for a
you can write without needing the dash-dash:
|
||
3. convert arguments into options! Options work pretty nicely together. | ||
|
||
## Combining short flags with optional values | ||
|
||
``` | ||
program | ||
.option("-o, --others [count]", "others servings") | ||
.option("-v, --vegan [count]", "vegan servings") | ||
.option("-l, --halal [count]", "halal servings"); | ||
program.parse(process.argv); | ||
|
||
if (program.others) console.log(`others servings: ${program.others}`); | ||
if (program.vegan) console.log(`vegan servings: ${program.vegan}`); | ||
if (program.halal) console.log(`halal servings: ${program.halal}`); | ||
|
||
``` | ||
|
||
In this example, you have to take note that optional options consume the value after the short flag. | ||
|
||
``` | ||
$ collect -avl | ||
any servings: vl | ||
``` | ||
|
||
If you wish to use optional options as boolean options, you need to explicity list them as individual options. | ||
|
||
``` | ||
$ collect -a -v -l | ||
any servings: true | ||
vegan servings: true | ||
halal servings: true | ||
``` | ||
|
||
### Behaviour change from v5 to v6 | ||
|
||
Before Commander v5, `-ob` expanded to `-o -b`, which is different from the current behaviour in Commander v6 as explained above. | ||
|
||
This new behaviour may be an issue for people upgrading from older versions of Commander but we do have plans to prioritise combining flags over combining flag-and-value in the future. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This advice applies to variadic options too. First go at adding mention of variadic...
Options can have a single optional value, but variadic options also take extra option values and have the same parsing complications.