What is the design pattern for processing command line arguments

Question

If you are writing a program that is executable from the command line, you often want to offer the user several options or flags, along with possibly more than one argument. I have stumbled my way through this many times, but is there some sort of design pattern for looping through args and calling the appropriate handler functions?

Consider:

myprogram -f filename -d directory -r regex

How do you organize the handler functions after you retrieve the arguments using whatever built-ins for your language? (language-specific answers welcomed, if that helps you articulate an answer)

Solution 1

I don't know of any documented "patterns" for processing.

I believe one of the oldest libraries/APIs for handling arguments is getopt. Googling "getopt" shows lots of man pages and links to implementations.

Generally, I have a preferences or settings service in my application that the argument processor knows how to communicate with. Arguments are then translated into something in this service that the application than then query. This could be as simple as a dictionary of settings (like a string setting named "filename").

Solution 2

I think the following answer is more along the lines of what you are looking for:

You should look at applying the Template Pattern (Template Method in "Design Patterns" [Gamma, el al])

In short it's overall processing looks like this:

If the arguments to the program are valid then
    Do necessary pre-processing
    For every line in the input
        Do necessary input processing
    Do necessary post-processing
Otherwise
    Show the user a friendly usage message

In short, implement a ConsoleEngineBase class that has methods for:

PreProcess()
ProcessLine()
PostProcess()
Usage()
Main()

Then create a chassis, that instantiates a ConsoleEngine() instance and sends the Main() message to kick it off.

To see a good example of how to apply this to a console or command line program check out the following link: http://msdn.microsoft.com/en-us/magazine/cc164014.aspx

The example is in C#, but the ideas are easily implemented in any other environment.

You would look at the GetOpt() as just the part that fit's into the argument handling (pre-processing).

Hope this helps.

Solution 3

You didn't mention the language, but for Java we've loved Apache Commons CLI. For C/C++, getopt.

Solution 4

Well, its an old post but i would still like to contribute. The question was intended on choice of design patterns however i could see a lot of discussion on which library to use. I have checked out microsoft link as per lindsay which talks about template design pattern to use.

However, i am not convinced with the post. Template pattern's intent is to define a template which will be implemented by various other classes to have uniform behavior. I don't think parsing command line fits into it.

I would rather go with "Command" design pattern. This pattern is best fit for menu driven options.

http://www.blackwasp.co.uk/Command.aspx

so in your case, -f, -d and -r all becomes commands which has common or separate receiver defined. That way more receivers can be defined in future. The next step will be to chain these responsibilities of commands, in case there a processing chain required. For which i would choose.

http://www.blackwasp.co.uk/ChainOfResponsibility.aspx

I guess the combination of these two are best to organize the code for command line processing or any menu driven approach.

Solution 5

A few comments on this...

First, while there aren't any patterns per se, writing a parser is essentially a mechanical exercise, since given a grammar, a parser can be easily generated. Tools like Bison, and ANTLR come to mind.

That said, parser generators are usually overkill for the command line. So the usual pattern is to write one yourself (as others have demonstrated) a few times until you get sick of dealing with the tedious detail and find a library to do it for you.

I wrote one for C++ that saves a bunch of effort that getopt imparts and makes nice use of templates: TCLAP

View more solutions

Comments

[Sean]

TCLAP is a fantastic CLI parsing library. The pre-parse setup of rules and post-parse extraction of the parsing of argv is very useful, intuitive and helps break the program up in to the correct discrete components (IMHO).

[Antonio Sesto]

It is a good choice. That library is a little bit complex compared to the old getopt, but allows also to use configuration files (substituting or integrating command line arguments).

[Plasmarob]

upvoted for sticking to the concepts rather than implementation. I feel like this should have been the chosen answer.

[Minh Tran]

-f, -d, -r seems to specify the information for a single ConcreteCommand. If the user specifies another combination of those flags -f -d, say, (or just -f or just -r or just -d, then each of those could represent another ConcreteCommand whose functionality (implemented by Execute()) differs from the ConcreteCommand initialized with -f, -d, -r.