Parsing values that contain command switches

Jun 21, 2010 at 4:06 AM

To start, thank you for the work you've put into this library.  It is very simple to get started with, and it solves a problem which almost every command line application must deal with.  I'm currently trying to use this library to parse command line arguments for a program I am working on, to which it is necessary to be able to pass argument values without any restriction on syntax.  I have noticed the following problem, assuming that I have an option with short name "a":

MyProgram.exe -a "-b something"

The command above will fail to parse, while the following will still work (note the blank space after the first quotation mark):

MyProgram.exe -a " -b something"


It would appear that the library is interpreting the argument after the "-a" as an additional argument, even though I have specified that "-a" is of type string and is required in my options class.


I've only briefly looked at the code, but it would appear the following unit test (or something near to it), following your existing form, demonstrates this issue:

        public void ParseValueContainingOptionSyntax()
          var options = new SimpleOptions();

          bool result = base.Parser.ParseArguments(new string[] { "-s", "-x something" }, options);

          Assert.AreEqual("-x something", options.StringValue);

Your library is certainly appreciated, but this currently presents a bit of a snag for me, as far as my ability to use it without issue.  I hope this is something you might consider addressing in a future version.




Aug 22, 2010 at 10:11 PM

When you execute a program form command line everything in double quote is a single argument.

This is not an issue but the default behavior of command line based apps.


Aug 22, 2010 at 10:32 PM
Edited Aug 22, 2010 at 10:33 PM


I'm afraid you misunderstood my issue.  I originally stated the same expectation that you have confirmed in your reply.  Everything in quotes should be treated as a single argument, but it is not.  In my example, despite being in quotes, my second argument "-b something" is incorrectly treated as two separate arguments by the library.  I was able to easily demonstrate the fact that it is splitting arguments whenever they start with a dash by including a leading space within quotes to work around the issue. 

The unit test which I included also supports this assumption.  The second argument should be read and preserved as a single string "-x something", and not split into two arguments.




Aug 1, 2012 at 1:13 PM

I came across this issue as well, if you have a string argument whos value is quoted and starts with a "-" the parsing breaks

I also solved it temporarily by just adding a leading space to the argument.

if you only have one option (short name "a") of a string type then the following happens when parsing arguments

testprog -a "-b testing"  --will fail parsing

testprog -a " -b testing" -- completely fine


Aug 3, 2012 at 8:10 AM
Edited Aug 3, 2012 at 8:11 AM

Hi all, the point is about value argument not option argument.

This is the canonical form:

someapp -a "your value" --arg2 "another value here"

The question is, there's a problem if you include a dash (-, prefix for short option) or two dashes (--, prefix for long option) in a value argument enclosed by quotes? Plese specify this.

But if the value argument contains a dash, because it contains an option specification inside, like this

someapp --myarg "value of my arg" "--myarg2 value of my arg2"

really there's no reason for that! (Or if there's please let me know.)


Aug 3, 2012 at 4:48 PM

Although I am no longer using this library, at the time that I was investigating it, it was important to have the ability to pass arguments in to one program, which would then be used as the arguments for another command line process called by the first program.  If the spawned program was to have command line switches they would need to start with a "-", but passing those was not possible given the issue that is being discussed.

I think it is hard to flatly say that no one will ever need to pass an argument to a command that starts with a dash.  Someone might want to create something as simple as a program that takes a message to write as an argument, such as:

WriteMessage -m "-H E L L O-"


Jan 8, 2013 at 10:54 AM

Passing negative values like -1 or -10 for an option can be a valid scenario.
So in order to use this you need to call the application like:

CommandLineTest.exe -myoption " -1"