args parser cannot accept option arguments starting with a hyphen

[DartBot]

<img src="https://avatars.githubusercontent.com/u/1381377?v=3" align="left" width="96" height="96"hspace="10"> Issue by hoylen
Originally opened as dart-lang/sdk#21958

---

What steps will reproduce the problem?

1. Run the program below with arguments "-t -32"

dart bin/test-args-hyphen.dart -t -32

What is the expected output? What do you see instead?

Expected: Temperature is: -32

Got: FormatException: Missing argument for "temperature".

It treats the option argument as another option instead of the argument to the "-t" option.

What version of the product are you using?

1.8.3

On what operating system?

linux_x64

Please provide any additional information below.

// Test program

import 'package:args/args.dart';

void main(List<String> arguments) {

  var parser = new ArgParser(allowTrailingOptions: true);
  parser.addOption('temperature', abbr: 't', help: 'degrees');

  var results = parser.parse(arguments);

  print("Temperature is: ${results['temperature']}");;
}

//EOF

[DartBot]

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

[nex3]

@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?

[hoylen]

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.

[nex3]

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

[seaneagan]

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

[nex3]

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