Skip to content
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

Merged
merged 12 commits into from
Sep 13, 2020
78 changes: 78 additions & 0 deletions optional-options-docs.md
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.

Copy link
Collaborator

@shadowspawn shadowspawn Aug 22, 2020

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.

.option('-c, --copies [number]') // 0 or 1 value
.option('h, --headers [files]') // 0 or more values
.option('-s, --source <files>') // 1 or more values

## Parsing ambiguity

There is parsing ambiguity when using option as boolean flag and also having it accept operands and subcommands.

```
program.command('example')
Copy link
Collaborator

Choose a reason for hiding this comment

The 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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The 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
.option("-o, --option [optionalValue]")

Copy link
Collaborator

Choose a reason for hiding this comment

The 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:

program.arguments('[file]');

Copy link
Collaborator

Choose a reason for hiding this comment

The 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
The utility in the example is named utility_name. It is followed by options, option-arguments, and operands. The arguments that consist of characters and single letters or digits, such as 'a', are known as "options" (or, historically, "flags"). Certain options are followed by an "option-argument", as shown with [ -c option_argument]. The arguments following the last options and option-arguments are named "operands".

https://docs.python.org/3/library/argparse.html
The add_argument() method must know whether an optional argument, like -f or --foo, or a positional argument, like a list of filenames, is expected. The first arguments passed to add_argument() must therefore be either a series of flags, or a simple argument name. For example, an optional argument could be created like:

yargs
.options()
.command()
.positional()

https://oclif.io/docs
Arguments are positional arguments passed to the command.
Flag options are non-positional arguments passed to the command. Flags can either be option flags which take an argument, or boolean flags which do not. An option flag must have an argument.

https://github.com/spf13/cobra#concepts
Cobra is built on a structure of commands, arguments & flags.
Commands represent actions, Args are things and Flags are modifiers for those actions.

Copy link
Contributor Author

Choose a reason for hiding this comment

The 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

Copy link
Collaborator

Choose a reason for hiding this comment

The 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:

operand (sometimes called a positional argument)

I do not see "operand" used very much apart from the Open Group, and currently considering "command argument" to match up quite nicely with Command.arguments().

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. process.args), option arguments, and command arguments.

.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
Copy link
Contributor Author

Choose a reason for hiding this comment

The 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" ?

Copy link
Collaborator

Choose a reason for hiding this comment

The 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 --sugar option taking an option count:

brew --sugar -- tea

you can write without needing the dash-dash:

brew tea --sugar

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.