Option Parsing: Argument Parsing
• CommentsThis is going to be an in-depth post on how argument parsing works in the Nito.KitchenSink.OptionParsing library, and a couple of ways the parsing can be modified.
General Option Argument Parsing Rules
First, a reminder about terminology; in this example, the “v” is the short option name, and the “3” is the option argument:
> CommandLineTest.exe -v 3
Also remember that an option argument may be required for an option, or it may be optional. If you need a refresher, read the earlier post options with optional arguments.
Required option arguments are allowed to begin with a dash (-) or forward-slash (/), but optional option arguments are not. To start an optional option argument with these characters, specify the argument using a full-colon (:) or equals sign (=).
Consider this example program, which just takes two string arguments, one required and one optional:
> CommandLineParsingTest.exe -r a -o b
Required Value: a
Optional Value: b
> CommandLineParsingTest.exe -r /a -o b
Required Value: /a
Optional Value: b
> CommandLineParsingTest.exe -r a -o /b
Unknown option b in parameter /b
> CommandLineParsingTest.exe -o "/b"
Unknown option b in parameter /b
> CommandLineParsingTest.exe -o:/b
Optional Value: /b
> CommandLineParsingTest.exe -o=/b
Optional Value: /b
Note that placing the argument in double-quotes does not allow the argument to start with a dash or forward-slash.
Reminder: the command shell has its own set of reserved characters (&
, |
, (
, )
, <
, >
, and ^
). These can be escaped using ^
, or they can be wrapped in double-quotes. Command shell escapes are described in more detail in the post on command-line lexing.
Implementing a Simple Argument Parser
Parsing an argument option is done in two steps. The first step is to parse that portion of the command line as a string, using the rules above. The second step is to parse the string into an instance of the corresponding property type on the option arguments class. Since the examples above used a property type of string, there was no processing during the second step.
It is possible to use only a part of the option parsing pipeline to get options and their arguments as strings. Pass a sequence of OptionDefinition instancess and a command line into the parser; the result is a sequence of Option instances (where each argument is typed as string). Details of these types will be covered in a future blog post.
The option parsing library uses a collection of “simple parsers” to convert from a string to a known type. By default, the simple parser collection understands how to parse bool; signed and unsigned 8-bit, 16-bit, 32-bit, and 64-bit integers; BigInteger; single and double-precision floating point; decimal; Guid; TimeSpan; DateTime; and DateTimeOffset. Strings, enumerations and nullable types are treated specially: strings are never parsed, enumerations use Enum.Parse, and nullable types are supported if their corresponding non-nullable types are supported. The built-in parsers all use the standard TryParse methods.
Say, for example, we wanted to accept an argument of type Complex. The Complex type is not included in the default simple parser collection (in fact, it does not even have a Parse or TryParse method!).
If we try to add it to our program, then whatever we pass as the argument value will just fail to parse:
> CommandLineParsingTest.exe -v (3,5)
Could not parse (3,5) as Complex
We can create a parser for the Complex type by implementing ISimpleParser. This interface only has two members: the type of the result and a TryParse method.
Once we’ve implemented our special parser, we need to pass it to the Parse method. To do this, we create a SimpleParserCollection, add our special parser, and pass the collection to the Parse method.
Our solution now looks like this:
> CommandLineParsingTest.exe -v (3,5)
Value: (3, 5)
We added a custom parser to the collection, and the option parsing library now understands how to parse a new type. We could add any number of Complex properties, and they would all use the new parser.
This is a powerful extension point, but what if we want to modify the way an extisting type is parsed?
Replacing a Simple Argument Parser
The default parsers in a simple parser collection only use the basic TryParse methods, which may not be exactly what is needed. SimpleParserCollection.Add will actually replace the parser for a given type if there is already a parser for that type.
We’ll use uint for our example. We want to allow either decimal numbers or hexadecimal numbers prefixed by “0x”. System.UInt32.TryParse(string) does not accept hexadecimal numbers:
> CommandLineParsingTest.exe -v 11
Value: 11
> CommandLineParsingTest.exe -v 0x11
Could not parse 0x11 as UInt32
Just like the last example, we’ll implement our own parser, and we’ll add it to the parser collection (replacing the default parser).
> CommandLineParsingTest.exe -v 11
Value: 11
> CommandLineParsingTest.exe -v 0x11
Value: 17
Our program now allows decimal or hexadecimal values for all uint argument values.
These custom parsers can be written for any type, including types specific for your program. The only type they won’t work on is string, since the simple parser collection just passes string values straight through.
Overriding the Simple Argument Parser
The examples so far have implemented a custom parser and added it to the parser collection. This changes the parsing behavior for every property of that type. Sometimes we just want to apply a parser to a single property; this can be done by using the SimpleParserAttribute.
This example defines a hex parser (without the “0x” prefix) and then uses it for only one of its properties:
> CommandLineParsingTest.exe -h 11 -d 11
HexValue: 17
DecValue: 11
Custom Parsers for Multiple Argument Values
Revisiting the problem of multiple argument values, we can use a custom parser for a cleaner solution. This example “sequence parser” uses the default simple parser for int types, which is easier to deal with than int.TryParse:
> CommandLineParsingTest.exe
> CommandLineParsingTest.exe -v 2,3,5,7
Values: 2 3 5 7
> CommandLineParsingTest.exe -v 2,3a,5
Could not parse 2,3a,5 as IEnumerable<Int32>
> CommandLineParsingTest.exe -v 2,3 -v 5,7
Values: 5 7
The last example above shows that the default behavior of the actual property setter is still overwrite, not append. If you want to allow appending sequences, you’ll need to change the setter to append each sequence to an internal collection.