13

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?

Cody Gray - on strike
  • 239,200
  • 50
  • 490
  • 574
Paul Wicks
  • 62,960
  • 55
  • 119
  • 146
  • 3
    Cast my vote for "roll your own." a) You learn from it, b) it's fun, and c) you won't have to worry about portability or depending on someone else's code, and d) you know you'll have all the features you want, and none of the ones you don't. However, I think I will be in the minority. – Chris Lutz Mar 12 '09 at 04:34
  • 10
    @Chris Lutz: unless you roll your own so it adheres very closely to the standard, then you are in danger of producing programs that are irritating to use. Using a standard option parser reduces the learning for everyone else (who uses your program), and usually simplifies maintenance too. – Jonathan Leffler Mar 12 '09 at 05:39
  • 2
    I just recently rolled out https://github.com/visionmedia/commander.c a port-ish of my ruby and node option parser – TJ Holowaychuk Jun 20 '12 at 15:55

6 Answers6

18

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
  • 38,128
  • 22
  • 77
  • 87
  • The bad thing about this library is that it is not a "header-only", as opposed to most other components of Boost. I never really understood why this is the case. – a06e Mar 14 '16 at 11:36
  • Just because the developer chose to make it that way. I've become less enamored of it since I wrote that too. It's good, and cross-platform, but I find that I prefer handling options with my own code most of the time. The time it takes me to write an option parser from scratch is often less than what it would cost me to figure out how to set up the library code to do the same thing, especially as I don't need to deal with configuration files, only command-line options. – Head Geek Mar 15 '16 at 13:28
  • 1
    The fact that Boost::Program_Options is not header-only is a problem, because Boost updates version frequently. This means that if you don't link statically to Boost::Program_Options, your program will not run in all machines with the wrong version of Boost! – a06e Mar 15 '16 at 14:08
13

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 the environment variable POSIXLY_CORRECT. 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 might find some useful extra information at What is the general syntax of a Unix shell command. You can also read the POSIX specification for command line conventions in the Utility Conventions chapter.

Community
  • 1
  • 1
Jonathan Leffler
  • 730,956
  • 141
  • 904
  • 1,278
  • There is only one bad thing about GNU getopt() and it is the license. – Anonymous Mar 12 '09 at 13:11
  • 2
    Yes - it is at least LGPL these days. It used to be full GPL. You can get non-GNU versions of getopt(). AT&T published the source on UseNet way back, for example. – Jonathan Leffler Mar 12 '09 at 13:36
  • 2
    A good specification of how the POSIX utilities are designed to work is given in the POSIX [Utility Conventions](http://www.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap12.html) chapter. – Jonathan Leffler Nov 25 '10 at 20:49
6

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
  • 222,467
  • 53
  • 283
  • 367
1

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
  • 2,011
  • 1
  • 12
  • 10
1

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
  • 33,371
  • 15
  • 110
  • 174
1

also there are popt.

vitaly.v.ch
  • 2,485
  • 4
  • 26
  • 36