args parser cannot accept option arguments starting with a hyphen about args HOT 6 CLOSED

<img src="https://avatars.githubusercontent.com/u/4865287?v=3" align="left" width="48" height="48"hspace="10"> Comment by lrhn

Added Pkg-Args, Area-Pkg, Triaged labels.

from args.

@hoylen Your example is ambiguous; there's no way for the parser to decide whether -32 is a value or a (potentially typoed) flag.

That said, there should be a way to pass this value; the parser should probably interpret a leading backslash in an argument value as an escape. This seems to be the standard among UNIX command-line programs. This could be interpreted as a breaking change, but it's only going to break the users of command-line apps who won't be able to add version constraints on args anyway. It's also quite minor, so I think it could be fixed in a patch release. @munificent, what do you think?

from args.

The use case is not ambiguous, since an option is specified using the addOption method and there is a different method for setting flags (addFlag). The argument parser expects to find an option argument after the "-t", so it should know not to treat "-32" as flag/option.

The implementation should follow the rules established by GNU getopt (and getopt_long), since that is what is familiar to developers and users. Certainly better than doing something that is inconsistent with known conventions. Otherwise, Dart command line programs will behave differently from non-Dart command line programs, and be confusing for users. The GNU getopt implementation has figured out how to treat the different situations (the above example was easy, since there is a space between the option and the option's argument, but the GNU getopt also has a convention for how to treat "-t3").

The GNU getopt is the defacto standard, since they invented the double-hyphen long arguments. So if Dart is to support them, it should follow the GNU getopt parsing rules exactly. Don't go about inventing new rules (e.g. backslash escaping) which only apply to Dart's argument parser.

from args.

All right, I buy that we should do the same thing as getopt_long here.

from args.

@nex3 is "-t-32" supported (without a space) ? I didn't see a test for it in the diff.

from args.

@seaneagan Yes. There's no test for that because it's not really ambiguous; there's no reason we'd even try to parse that as an option.

from args.