Support options before arguments

[agc93]

Especially for Unix/Linux platforms, the convention is usually to provide options before arguments:

Usage: grep [OPTION]... PATTERN [FILE]...
Usage: tar [OPTION...] [FILE]...
systemctl [OPTIONS...] {COMMAND} ...

Using boolean options before arguments currently gets incorrectly interpreted as assigning a value to the option flag. Would be good to support this ordering (preferably alongside existing behaviour).

[woutervanranst]

FYI I came here after looking through the issues. I believe the related error message is

       restore --keep-pointers c:\Users\Wouter\Documents\Test
               ^^^^^^^^^^^^^^^ Can't assign value

CommandParseException: Flags cannot be assigned a value.

This is not an issue with Options that have a value (eg. --keep-pointers true)
+1 on supporting the Linux/CLI convention

[dswisher]

Even as a developer, I was quite confused by the "Can't assign value" error message. Ideally, options would be allowed before arguments, but at the very least, could the error message be improved?

[FrankRay78]

Cake has an open issue closely related to this, cake-build/cake#3280, basically looking to move all the cake command options before the build script argument, allowing any options following the command argument to automatically become remaining arguments.

[FrankRay78]

This issue is occuring due to the way that CommandTreeParser is handling Options, namely peeking ahead to the next argument to determine what to do.

The following image is when I've specified the following on the command line --version --somethingelse and it's currently parsing the --version Option. you can see that it's peeked ahead and discovered another Option:

It knows to correctly ignore the following somethingelse Option and just proceed with the 'No value?' code further on.

When I specify the following on the command line --version somethingelse, then when it is parsing the --version Option, it peeks ahead and discovers something following it of TokenKind String:

CommandTreeParser.ParseOptionValue proceeds to attempt to set the --version Option to this value, unsuccessfully:

---

For @woutervanranst 's example above to work correctly,

restore --keep-pointers c:\Users\Wouter\Documents\Test

I guess the CommandTreeParser needs to

1. check if --keep-pointers is a flag (ie. boolean value specified on the command settings class)
2. if yes, then ignore the peek, proceed with the 'No value?' code further on, and parse c:\Users\Wouter\Documents\Test on the next pass (which should be handled here I suspect:)
   
3. if no, then attempt to set the --keep-pointers option value to c:\Users\Wouter\Documents\Test

[woutervanranst]

I m assuming we don t need to reinvent the wheel here, I expect there are nasty edge cases we re missing - linux CLI parsers would have solved this already

[FrankRay78]

I'm happy to have a go at this issue @patriksvensson - please assign it to me.

[patriksvensson]

@FrankRay78 Done!

[FrankRay78]

This issue can be closed/marked as complete @patriksvensson, now that PR #1048 has been successfully merged.