Please add support for forward slash

[BrianCatlin]

It would be great if there were a parser setting that would allow forward slash ('/') to be used as well as dash to distinguish options on the command line, because most Windows console apps support both

[moh-hassan]

The library is compliant to GNU getopt that support single/double dash. Forward slash "/" violate that standard.

[BrianCatlin]

So what? I'll bet it runs on far more Windows systems than Linux systems. Being compliant with getopt is fine, but if someone wants to use slash, it may increase the adoption of your library, so why not support it? Make it an option that has to be enabled, that way the getopt purists get what they want and those who want to use a slash get what they want. Everyone is happy.

[moh-hassan]

Make it an option that has to be enabled

Even making it an option, forward slash "/" may cause major changes, some of these changes are:

• use "/" with both single letter command /c /a and multi-char commands /online
• help is invoked by /h or /?
• DashDash that enable the end of options delimiter in the custom Parser should be disabled.
• Add Dash in HelpText should be modified.
• The command --version should be removed(it's not standard command in windows).

Microsoft is now moving towards supporting the Posix use of - to denote parameters as documented in their PowerShell Command-Line Standard documentation. This is because Windows operating system now sees both \ and / as directory separator characters.

see Use dash arguments to msbuild

PR is welcome to support forward slash "/" as an option for the Parser.

[x10an14]

@BrianCatlin What about the following?

<cli program> /flag1 /flag2 <flag2 value> /Linux/Absolute/Path/To/File

In my above example, /Linux/Absolute/Path/To/File is a positional argument, which most definitively is a part of the GNU getopt standard...
So you'd have to ensure not to break that backwards compatibility...

[BrianCatlin]

Personally, I don't care about Linux. There are several orders of magnitude more Windows users than Linux users. Do Linux users care about IBM 370 users? (yes, I know that this package doesn't support IBM 370) I'm only asking for Windows support

[x10an14]

@BrianCatlin Of course there are many orders of magnitude more people daily logging into a Windows machine and interacting with it through mouse/keyboard/touchscreen than Linux, but let me ask you the following:

• Why do you care about the end-users who don't write programs? I for one (and I'd haphazard a guess many others) wouldn't trust your claim if your next (updated) claim is that an order of magnitude developers are Windows-only users (and by choice at that).

• There's a reason Linux is so pervasive, so one might want to weigh the argument of "there are more Linux machines running in production world-wide than Windows, so maybe support the as-such dominant OS family?".
  (I'll find you a source for this if you so desire, but it shouldn't be that hard to believe if you look around the web for what types of servers reply - I don't belive you'll find neither Apache nor Nginx running on a Windows server more than a smidge of a percentage the amount of times you'll find the same running on a Linux box).

• Finally - and what I hope is my most heavily weighing argument - you write

  I'm only asking for Windows support

  Why do you phrase your question so when Windows is already supported through the use of - as opposed to /?
  I'd be very much interested in hearing where in the Windows (OS family) itself (and not something someone non-Microsoft has written locally) requires you to only use /.

In the end, I'd really recommend taking a look at the link provided by @moh-hassan (this one: dotnet/docs#7732), and explain to us why - when Microsoft seems to claim this is a sane change to accomodate the greatest amount of users - you disagree with their claim that you're not accommodated/enabled/supported when on Windows through the usage of -.

Edit: Apologies for clumsy English - not my first language.

[BrianCatlin]

No worries on your English. It is a crap language and you're doing very well with it.

I don't want to get into a flame war about the merits of any of the operating systems or their popularity. From my perspective, an operating system is a tool and is fit for a number of purposes, and I use the right tool for the job - and yes, that includes Linux on occasion. You may not realize it, but we abolished slavery in 1864 so no one is 'forced' to use - or develop for - Windows.

Microsoft is not the monolithic entity that most people believe it is, and the groups are very independent. Just because one group (PowerShell) is pushing the '-' as a command line switch does not mean that is the view of the entire corporation. Most - I'm tempted to write 'nearly all', but I'm not 100% certain and I don't have the time to check each tool - of the developer tools in the SDK and WDK (Windows Driver Kit) support the '/'

[farangkao]

The question has been asked why do we need the support for /option as well as --option ?

/option was the default in MS Dos/Windows since years.
Open a cmd under Windows 10 ,and dir --help get you nothing ,but dir /? works.

So yes, when we design new Software, we should consider to switching to linux style parameters, but:
sometime there is a need to mimic existing behaviors.

You like to write a replacement application ,that has to support the legacy parameters ,because other systems are calling that application with / parameters.
Or you have Users that already have links to "Someones.exe /option=test" ,and if you upgrade to a new CommandLine Parser, you don't want to have the Users to refresh all their links.

Some good reasons why it's needed.

I understand that the author(s) might be not interested for support ,but then there is still the possibility to Fork this Code and add it by yourself.

Or if no negative effects are caused, even a Merge Request.

A Simple workaround would be to replace all "/" to "--" before running it thru this Library, quick and dirty solution as long there is no need for "/" in other parameters.

[moh-hassan]

@farangkao
PR is welcome to support forward slash "/" as an option for the Parser.
Have a look to the expected changes

A Simple workaround would be to replace all "/" to "--" before running it thru this Library,

I'll investigate your suggestion.

/cc @gsscoder

[gsscoder]

Agree with @moh-hassan,
get_opt standard is sufficienlty expressive and MS too is moving forward it.

@farangkao, thank you for the PR, but for the moment I think it's better not support / options.

Have a nice day