views:

1276

answers:

7

I've done some looking and there are a whole lot of libraries for command line option parsing, but it is difficult to differentiate between them. Does anyone have any experience with any of them? Is one harder/better/faster/easier/whatever than any of the others? Or should I just grow my own?

A: 

if you are using linux/unix then getopt is the option parser for you it. works on almost all flavors of unix and is easy to use

serioys sam
+5  A: 

For many purposes, the GNU getopt() and getopt_long() functions are good choices.

The GNU getopt() is for single-letter option arguments and hews fairly close to the POSIX standard behaviour, and can be persuaded to behave more orthodoxly by setting POSIXLY_CORRECT in the environment. The difference is that GNU getopt() recognizes option arguments after the first non-option argument, and permutes the arguments so that all the option arguments are processed before any of the non-option arguments. This sometimes matters - though the contexts tend to be a little esoteric. There are a few other extra tricks available

The GNU getopt_long() is the best mechanism for dealing with long-options such as --help. It can handle optional arguments, matching single-letter options and all sorts of things.

There are numerous other packages available that handle options in various ways.

(Perl has a plethora of Getopt modules, reflecting how much effort has been put in over the years.)

You may get some extra information from Which Command Line Commands Style Do You Prefer

Jonathan Leffler
There is only one bad thing about GNU getopt() and it is the license.
Anonymous
Jonathan Leffler
+11  A: 

If you want something completely cross-platform, I've found the Boost::Program_Options library to be very good. There's something of a learning curve to setting it up, but once you master that, it simplifies things greatly.

Head Geek
+1  A: 

I use the system implementation of getopt_long() for most things, however you might need to be more portable which prohibits the use of such POSIX creature comforts.

Here is the standard regarding the POSIX view of command line options if you are in a position where getopt() / getopt_long() are just not available and need to roll your own. You might also want a look at what POSIX has to say about help / option summary displays (I can't find a link to that part of the standard off hand).

Personally, I don't like using programs that do not take --long-options, because remembering the short options is a pain and no two programs use the same.

Tim Post
+5  A: 

boost::program_options is pretty good and has a nice C++ interface that can check that option parameters have a certain type (like 'int') and store them directly into variables.

It also supports to load the "options" from a config file, so you get a config file parser for free. This way you can very easily allow to override all the configuration settings from the command line or add all the command line options to the config file, which makes it very flexible.

sth
+4  A: 

Already asked at SO here, and before that here.

dmityugov
+1  A: 

also there are popt.

vitaly.v.ch