Add support for ignoring unrecognized options/flags.

[pq]

In analyzer_cli and analysis_server we work around this limitation by wrapping an ArgParser and filtering out unknown options ourselves but it would be far better if this were in args proper.

[sethladd]

Ah, I had this request a while ago. Would love to be able to turn on "ignore unrecognized flags"

[sethladd]

Here's the original request: https://code.google.com/p/dart/issues/detail?id=14786

[seaneagan]

How do we tell if --unknown is intended as a flag or value-taking option?

foo --known --unknown bar

when a positional is provided and allowed after it (see also #110).

[seaneagan]

Perhaps assume a value taking option, since the user can use -- to explicitly start positionals when that assumption is wrong:

foo --known --unknown -- bar

[seaneagan]

I've started working on this.

[nex3]

If we have to assume that unknown flags take values, we should require that -- be passed when unknown flags are allowed. Otherwise it becomes too easy to accidentally misinterpret a command line.

[seaneagan]

The end user shouldn't have to care about "unknown options". That's an implementation detail. It would be a confusing error message: 'must include "--" when unknown options are allowed'.

It'd also be a terrible UX to always have to use -- when using a CLI.

Something less drastic may make sense though, like requiring -- when the last - (or --) - prefixed arg is unknown, and followed by a value arg. So this is disallowed:

foo --known-flag --unknown bar

The error message could be something like 'Cannot understand "--unknown bar". Please disambiguate with "--unknown bar --" or "--unknown -- bar"'.

These would be fine:

foo --known-flag
foo --unknown bar --known-flag
foo --unknown
foo --unknown=bar

[nex3]

Existing Dart tools that allow unknown options do so only when an --ignore-unrecognized-flags option is passed, so I assume that's what's desired here. Always ignoring all unknown options without the user explicitly asking for it seems like a bad experience all around, silently masking typos and swallowing input.

Something less drastic may make sense though, like requiring -- when the last - (or --) - prefixed arg is unknown.

What if they pass foo --unknown bar --known? If allowTrailingOptions is false, this could be intended as either foo --unknown=bar --known or foo --unknown -- bar --known. If it's true, it could be intended as either foo --unknown=bar --known or foo --unknown --known bar. I don't think you can get away with only caring about ambiguity for the last argument.

[seaneagan]

Just because the arg parser doesn't validate the unknown args doesn't mean the program itself doesn't.

[seaneagan]

my last comment assumes that the unknown args are exposed on the ArgResults either in the existing ArgResults.options or a new ArgResults.unknownOptions. BTW, which do we prefer?

[nex3]

I don't understand how your point bears on the parser ambiguity. Such an ambiguity means there is no canonical result of the parse for those situations; that's a problem regardless of what the program does after parsing.

[seaneagan]

Sorry, I was responding to:

Always ignoring all unknown options without the user explicitly asking for it seems like a bad experience all around, silently masking typos and swallowing input.

Regarding:

What if they pass foo --unknown bar --known? If allowTrailingOptions is false, this could be intended as either foo --unknown=bar --known or foo --unknown -- bar --known.

I never understood why I would want allowTrailingOptions to be false (especially as the default). As an end user, if I do foo bar --known I certainly meant the same as foo --known bar, but if the implementor of foo didn't explicitly set allowTrailingOptions: true, then this will silently misinterpret my args. If I'm passing dynamic args, and want to protect against a string that happens to begin with "--", then I should just use a "--" arg to disambiguate. What is the use case for allowTrailingOptions: false?

If it's true, it could be intended as either foo --unknown=bar --known or foo --unknown --known bar.

I agree. Need to think more about how to handle this.

I don't think you can get away with only caring about ambiguity for the last argument.

There is at least no ambiguity when no unknown options are passed.

[nex3]

I never understood why I would want allowTrailingOptions to be false (especially as the default). As an end user, if I do foo bar --known I certainly meant the same as foo --known bar, but if the implementor of foo didn't explicitly set allowTrailingOptions: true, then this will silently misinterpret my args. If I'm passing dynamic args, and want to protect against a string that happens to begin with "--", then I should just use a "--" arg to disambiguate.

We agree; the plan is to change it to default to true at some point.

What is the use case for allowTrailingOptions: false?

For situations like pub run where the trailing end of the command is itself a sub-command. It would be pretty unpleasant if anyone using pub run had to write pub run -- whenever they wanted to pass a flag to the executable they were running.

[seaneagan]

I think we just need to disallow any occurrences of --unknown value while still in the option parsing state (before -- if allowTrailingOptions is true, before the first known positional otherwise). In this case the user needs to disambiguate either via --unknown=value or --unknown -- value. --unknown value -- won't work since a -- arg doesn't say anything about the args before it, only those after it.

[nex3]

As I understand it, the point of this feature is to be able to pass flags that work for some executables but not for others. If that's the case, disallowing --unknown value will be very confusing if the flag was tested on an executable where it was known and then later passed to an executable where it wasn't.

[seaneagan]

Turns out I don't need this for my use case, so I don't have any current plans to work on this any further.

[pq]

Looks like there is no longer a pressing need for this.