Support also "/" for Parameters

[jogibear9988]

No description provided.

[gsscoder]

This must be discussed...

[indigotock]

It's common on Windows (maybe others?) for command line arguments to use / instead of (or as well as) -. Here's the a snippet of the output of copy /?:

  source       Specifies the file or files to be copied.
  /A           Indicates an ASCII text file.
  /B           Indicates a binary file.
  /D           Allow the destination file to be created decrypted
  destination  Specifies the directory and/or filename for the new file(s).
  /V           Verifies that new files are written correctly.
  /N           Uses short filename, if available, when copying a file with a
               non-8dot3 name.
  /Y           Suppresses prompting to confirm you want to overwrite an
               existing destination file.
  /-Y          Causes prompting to confirm you want to overwrite an
               existing destination file.
  /Z           Copies networked files in restartable mode.
  /L           If the source is a symbolic link, copy the link to the target
               instead of the actual file the source link points to.

I'm assuming that's what this is about, but I haven't tested the code.
I think it's a good idea! I think the library should be able to follow convention when it can, it would make for a better experience at least.

[alexanderfast]

While it is common for Windows the library has thus far stuck to the gnu get opt syntax. Changing this is not a decision to be taken lightly, it needs to be done well. The biggest drawback is probably that this will be a step away from the "convention over configuration", something that is listed on the project front page as a feature, since this is something that the user of the library would have to decide upon and specify in code. My guess is that it will be unnecessarily complex to support both implicitly/silently.

[gsscoder]

@jogibear9988, while I'm open upon adding features to save time on data validation and transformation, I'm quite conservative on syntax.

As @mizipzor states the library implements the basic GNU C getopt() function going beyond only for features said. Now it's a just a link in the bottom of README.md but he used to be the project subtitle.

@jogibear9988 in my opinion *nix style is far more espressive and has its root on getopt(). On the other side the Windows forward slash of defining options clashes with *nix path and I think is a trend born only to differentiate OSes.

Said that should be quite straightforward allow both styles, I think it's not a good idea to allow both at the same time. I suppose that this setting could be expressed in ParserSettings or in a class-wide attribute.

Anyway it's an heavy modification and must be discussed with more people.

I want to add that as always I'm happy of people active interest in this project!

cc/ @nemec @gimmemoore

[nemec]

I agree with @gsscoder and @mizipzor that adding a '/' option is not in the spirit of the library. One important difference are long options, where Unix doubles up the dash while Windows uses only a single slash for short and long (I'm not sure the pull request linked above handles that distinction, but I haven't compiled it yet).

If it is allowed, it should definitely be a configuration option on the parser that chooses one or the other (not both). The only convention I can think of would be to switch based on which OS is running, but I don't like that idea at all (I prefer getopt style even on Windows).

We may also want to consider adding a Powershell style, too, which is just the Windows style with - instead of /.

[gsscoder]

@nemec, correct.
About Powershell style I want to add that recently various *nix tool use -longname or a single hyphen for both short and long options. I see it more as a trend that as a design decision.

I want to add that often people forget the full getopt() spec... For example you can group short options:

$ app -abcd
# also with a value if the last option is not a switch
$ app -abcd10

or feeding a value to a long name using an equal token:

$ app --longname=value

For quote just ones...

A cool idea could be to expose the internal Core namespace to allow the maximum flexibility, but in it's actual state is designed for internal use and absolutely not ready as public API. Exposing this different level of abstraction, will also break the library motto of simplicity.

[johnddx]

Exposing the internal Core namespace is a good idea, once it's ready, but I don't really like it for solving this problem.

I agree with the axiom of simplicity. I also see a lot of value in a single library which enables a developer to implement any of the more common CLI conventions, as requirements dictate. I don't think these points are incompatible. The number of conventions in common use, and which is being discussed here, is fairly small. As such I think it's quite reasonable for the library to support multiple conventions without undermining its pillar of simplicity. The desire for consistency is satisfied in another way: a developer can use the same parser library regardless of which syntax he employs. If one is developing a Windows application, they may not be able to conform to a specific set of design choices, and it would be a shame if that means they couldn't use this library as a result. A library (usually) can't define requirements, requirements tend to dictate which library gets used.

Being the case, I would rather the developer have access to a high-level policy option that allows a choice between a few broad patterns, and which map to a handful of other more detailed options which can also be customized. For example:

1. getopt() Syntax (default)
   • "-" for short option prefix
   • "--" for long option prefix
   • short option grouping allowed
2. Windows Legacy Syntax (e.g. "findstr")
   • "/" or "-" for short option prefix
   • long name options disallowed
   • short option grouping allowed
3. Windows "dir" Syntax
   • "/" or "-" for short option prefix
   • "/" or "-" for long option prefix
   • short option grouping disallowed
4. Powershell Syntax
   • "-" for short option prefix
   • "-" for long option prefix
   • short option grouping disallowed
5. custom syntax
   • developer shoots self in foot as needed

Since there is a default policy, the complexity of choosing and/or customizing a policy would be hidden until the developer needed it.