library for command-line parameters
-
Hello Experts, one of the console applications I wrote is about to get modified to do a similar job to the one it was first designed to do. Its command-line parameters parsing works. But I never have been really happy with it. This example
tool.exe SetDo FirstLed On
should make an attached device switch its first LED on, obvisously. And it does so. What bothers me is that
SetDohas to be the first parameter,FirstLedthe second andOnthe third. No way for the user to put an option beforeSetDo. Since the modifications will change the possible actions anyway, I thought of finding a more standard library instead of using my own parsing. First I checked the GNU getopt .NET port[^] and found using it horrible. You have to specify a format string, only for one-character options and aswitchstatement that matches the format string. Then you can attach long options that use a short option to determine what action they trigger. That approach appears to be inspired by sprintf's format string[^], which we all know about and that it works. It just is so unintuitive to use from a programmer's point of view. My second try was Mono.Options[^]. It doesn't require a format string. You just have to fill a generic list with one object per supported command. Short and long option names are supported in the object's constructor, along with a description of the command (for the auto-generated help screen) and a method to call during runtime. Now I recognize that there's still a lot of work to do by hand since not all my options are boolean switches. The example I gave above uses two enumerations, one that holds all possible digital outputs to manipulate, the other for the state that should be the result of the manipulation. It doesn't look like there is an easy way to get that into the auto-generated help file, nor that the parser can handle situations like "Option A must preceed one of enum B's values followed by enum C's value -
Hello Experts, one of the console applications I wrote is about to get modified to do a similar job to the one it was first designed to do. Its command-line parameters parsing works. But I never have been really happy with it. This example
tool.exe SetDo FirstLed On
should make an attached device switch its first LED on, obvisously. And it does so. What bothers me is that
SetDohas to be the first parameter,FirstLedthe second andOnthe third. No way for the user to put an option beforeSetDo. Since the modifications will change the possible actions anyway, I thought of finding a more standard library instead of using my own parsing. First I checked the GNU getopt .NET port[^] and found using it horrible. You have to specify a format string, only for one-character options and aswitchstatement that matches the format string. Then you can attach long options that use a short option to determine what action they trigger. That approach appears to be inspired by sprintf's format string[^], which we all know about and that it works. It just is so unintuitive to use from a programmer's point of view. My second try was Mono.Options[^]. It doesn't require a format string. You just have to fill a generic list with one object per supported command. Short and long option names are supported in the object's constructor, along with a description of the command (for the auto-generated help screen) and a method to call during runtime. Now I recognize that there's still a lot of work to do by hand since not all my options are boolean switches. The example I gave above uses two enumerations, one that holds all possible digital outputs to manipulate, the other for the state that should be the result of the manipulation. It doesn't look like there is an easy way to get that into the auto-generated help file, nor that the parser can handle situations like "Option A must preceed one of enum B's values followed by enum C's valueThere are many command line parser articles available on this site. The following is just a sample that a simple search found:
Commander - A Command Parser[^]
C#/.NET Command Line Argument Parser Reloaded[^]
C# command line parsing[^]
Advanced command line parser class for .NET[^]
C#/.NET Command Line Arguments Parser[^]
Intelligent Command Line Parser[^]
Simple Command Line Parser[^]
CCmdLine - A command line parser[^]
Lightweight C# Command Line Parser[^]
Powerful and simple command line parsing in C#[ -
Hello Experts, one of the console applications I wrote is about to get modified to do a similar job to the one it was first designed to do. Its command-line parameters parsing works. But I never have been really happy with it. This example
tool.exe SetDo FirstLed On
should make an attached device switch its first LED on, obvisously. And it does so. What bothers me is that
SetDohas to be the first parameter,FirstLedthe second andOnthe third. No way for the user to put an option beforeSetDo. Since the modifications will change the possible actions anyway, I thought of finding a more standard library instead of using my own parsing. First I checked the GNU getopt .NET port[^] and found using it horrible. You have to specify a format string, only for one-character options and aswitchstatement that matches the format string. Then you can attach long options that use a short option to determine what action they trigger. That approach appears to be inspired by sprintf's format string[^], which we all know about and that it works. It just is so unintuitive to use from a programmer's point of view. My second try was Mono.Options[^]. It doesn't require a format string. You just have to fill a generic list with one object per supported command. Short and long option names are supported in the object's constructor, along with a description of the command (for the auto-generated help screen) and a method to call during runtime. Now I recognize that there's still a lot of work to do by hand since not all my options are boolean switches. The example I gave above uses two enumerations, one that holds all possible digital outputs to manipulate, the other for the state that should be the result of the manipulation. It doesn't look like there is an easy way to get that into the auto-generated help file, nor that the parser can handle situations like "Option A must preceed one of enum B's values followed by enum C's valueNo other responses? Having given it some more thought... If I understand you correctly, you are using Enumerations for each parameter. Why not put them all in one enumeration?
-
No other responses? Having given it some more thought... If I understand you correctly, you are using Enumerations for each parameter. Why not put them all in one enumeration?
Why? You covered it with that huge pile of links to various libraries!
A guide to posting questions on CodeProject[^]
Dave Kreskowiak -
Why? You covered it with that huge pile of links to various libraries!
A guide to posting questions on CodeProject[^]
Dave KreskowiakI'd still prefer to see some discussion.
-
I'd still prefer to see some discussion.
OK, cool. I'd layout the command line format like this, following the old DOS spec of everything inside square brackets being optional:
tool.exe \[\[/option\] \[value\]\] \[/cmd "targetNoun actionVerb value"\]That would make it easier to parse as each switch is either a "Named Switch" or a "Named Value". The CMD switch could even be extended like this:
/cmd "targetNoun actionVerb \[value\]\[;...\]"making it easier to parse for multiple commands to execute in the specified order.
A guide to posting questions on CodeProject[^]
Dave Kreskowiak -
OK, cool. I'd layout the command line format like this, following the old DOS spec of everything inside square brackets being optional:
tool.exe \[\[/option\] \[value\]\] \[/cmd "targetNoun actionVerb value"\]That would make it easier to parse as each switch is either a "Named Switch" or a "Named Value". The CMD switch could even be extended like this:
/cmd "targetNoun actionVerb \[value\]\[;...\]"making it easier to parse for multiple commands to execute in the specified order.
A guide to posting questions on CodeProject[^]
Dave KreskowiakI was thinking... TOOL action /LED=n|(list) /STATE=ON|OFF e.g. TOOL SET /LED=1 /STATE=ON TOOL SET /LED=(3,5,7) /STATE=OFF (But what other actions are there?) Or TOOL /ON=n|(list) | /OFF=n|(list) ... e.g. TOOL /ON=1 /OFF=(3,5,7) /ON=2
-
I was thinking... TOOL action /LED=n|(list) /STATE=ON|OFF e.g. TOOL SET /LED=1 /STATE=ON TOOL SET /LED=(3,5,7) /STATE=OFF (But what other actions are there?) Or TOOL /ON=n|(list) | /OFF=n|(list) ... e.g. TOOL /ON=1 /OFF=(3,5,7) /ON=2
Yeah, we have no idea what else he's got to control, nor how he has to refer to them. The LED=n might work for him but it really depends on the complete list of items he needs to control and the verb and value options available for each of those. When he knows that, then he might be able structure a standard format command line if there are a lot of possibilities or, if not, simplify it to what you've said.
A guide to posting questions on CodeProject[^]
Dave Kreskowiak