Comments (17)
Ah, I had this request a while ago. Would love to be able to turn on "ignore unrecognized flags"
from args.
Here's the original request: https://code.google.com/p/dart/issues/detail?id=14786
from args.
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 #12).
from args.
Perhaps assume a value taking option, since the user can use --
to explicitly start positionals when that assumption is wrong:
foo --known --unknown -- bar
from args.
I've started working on this.
from args.
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.
from args.
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
from args.
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.
from args.
Just because the arg parser doesn't validate the unknown args doesn't mean the program itself doesn't.
from args.
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?
from args.
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.
from args.
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
? IfallowTrailingOptions
is false, this could be intended as eitherfoo --unknown=bar --known
orfoo --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
orfoo --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.
from args.
I never understood why I would want
allowTrailingOptions
to be false (especially as the default). As an end user, if I dofoo bar --known
I certainly meant the same asfoo --known bar
, but if the implementor offoo
didn't explicitly setallowTrailingOptions: 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.
from args.
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.
from args.
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.
from args.
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.
from args.
Looks like there is no longer a pressing need for this.
from args.
Related Issues (20)
- Overhaul usage errors to not use exceptions
- Examples for CommandRunner aren't correct on pub page HOT 3
- Statically typed argument parser (possibly with code generator)? HOT 3
- Add a CommandRunner example HOT 2
- Why is `CommandRunner._usageWithoutDescription` private?
- Promote Command.argResults to be non-nullable HOT 1
- Make allowed options case insensitive
- How to add default command?
- Provide the function to print strings in nice columns
- Standards used in docopt. HOT 2
- [Feature request] Show command alias in usage HOT 3
- Command CommandRunner Platform.executableArguments HOT 3
- use of 'mandatory' options breaks handling of the help flag
- Feature request: parse complete command string to List<String> args HOT 3
- Analogue of '::' GNU getopt extension? HOT 1
- `--` needs to be escaped on Windows HOT 2
- Usage should be able to show additional info for trailing options (rest)
- Setting the mandatory parameter of the addOption function to true has no effect. HOT 1
- `takesArguments` should change the usage text
- Incorrect message in `dart_site --help` HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from args.