Using Windows like "/" short prefixes don't work

[veriotis]

When trying to use Windows like "/" short prefixes via "parser.ShortPrefix("/")" such short options don't work or can't be matched. Using this kind of flags or value flags for short options ( /h /v /i ... etc.) don't work:

> test.exe /h
Flag could not be matched: h
  test.exe {OPTIONS}

    This is a test program.

  OPTIONS:

      /h, /help                         display this help section
      /v, /version                     show the program version
      /longopt                         use longopt opt
      * Required arguments: *
      /i[file], /input:[file]           the input file to deal with
      /o[file], /output:[file]       the resulting output file

These also don't work: /i [file] /o [file]

Further I think if such Windows like setable short options "/" would work, they would at least for short value flags /x:[value], also probably need to offer a setable short seperator ":" in order to be somehow slightly more Windows conform and distinguishable as an short flag with a value argument.

[Taywee]

That is actually technically working as designed. The issue is that the short prefix and long prefix can't be the same. Both are considered long prefixes in that case. When you lead an option with a "/", the parser is determining from that point that it's a long option. You could fix this by specifying all those options as long options instead of short ones, in which case you won't be able to use "/i[file]", but would have to use "/i [file]" or "/i:[file]".

The difficulty here is that parsing is supposed to be unambiguous. In the case of "/ifile", how can the parser unambiguously tell that it is supposed to be referring to a short option "i" with an argument of "file" or a long option "ifile"?

This is definitely a bug in the parser, because it presents you a help menu showing that it should be possible. Really, it should either handle the case, find a way to unambiguously resolve it, or should throw an error like "ShortPrefix may not match LongPrefix" and kill the program. I'm leaning toward the latter.

[veriotis]

Yes using only long options would work, but then when using "/i:[file]" and "/input:[file]" both two options for one and the same command (as an alternative to a short and long option for one command), the layed out help text won't be printed out in a compact manner for both together on just one line.

The difficulty here is that parsing is supposed to be unambiguous. In the case of "/ifile", how can the parser unambiguously tell that it is supposed to be referring to a short option "i" with an argument of "file" or a long option "ifile"?

AFAIK the Microsoft command line standard is to use "/x arg" or "/x: arg" according to their technet library:

<slash><parameterName> <space>+ <argumentString> | <slash><parameterName> ‘:’ <space>* <argumentString>

...where +” means 1 or more, and “*” means 0 or more!

So with that "/i file" as a short option and "/i: file" as long option, the parser could for Windows style (detect it when a "/" is defined and used), look instead for:

short := </><char><space><arg>
long := </><char>+<:><arg> | </><char>+<=><arg>

in order to distinguish these two value option types. - Also short and long options without any arguments are probably distinguishable, since the short option then has only two chars "/x" followed by a space, where the long would logically have more than two chars "/xx*".