views:

287

answers:

4

Hi guys,

to do a proper Linux/unix styled application, what is the best choice (eg. afaik ls uses getopt_long but for example ffmpeg getopt_long_only). Which one do you recommend?

Cheers,

+1  A: 

Neither. User either argp_parse or libpopt.

William Pursell
What's the advantage of argp_parse over getopt_long ?
Emanem
A: 

I've never used getopt_long_only, but it seems like it would have to do more lookups, as it has to look at both the long and short options if an unknown flag starts with a single -:

If an option that starts with '-' (not '--') doesn't match a long option, but does match a short option, it is parsed as a short option instead.

-- man getopt_long_only

R. Bemrose
I know, thanks, but what is better to use in your opinion?
Emanem
+1  A: 

I'd say for "proper gnu/linux style" you should use getopt_long() and provide long options for most options (and sometimes long option only). Most command line interfaces follow this.

A: 

In my opinion, the following things are usually true:

  • Users love long, natural language options because they are easy to remember.
  • Users who write scripts to wrap programs that have hundreds of options love short options.

If a program gets big enough, it will eventually run out of short option combinations that make any sort of sense when compared to the canonical option. For instance, -Z might be the same as a long option that begins with a totally different letter. At that point, especially for a single maintainer, the option parsing code becomes a headache to maintain.

You have a few choices when that happens:

  • Use something like gengetopt to write that code for you from a template
  • Use only long options (usually a bad idea)
  • Try and keep your program down to 52 options (a-z A-Z) (usually a bad idea)
  • Implement options where short options just become switches that don't take arguments, use long options for those that do
  • A flurry of other methods that make perfect sense to you and little sense to users

Mix in different locales, and you really begin grasping the pain.

When I sit down to write a tool that takes lots of options, the first thing I usually do is write the code to parse the arguments, this helps to plan the flow of the program and becomes an outline. You just make each option work after that.

In other words, if you get to the point where options become such a chronic pain, its usually indicative of a program that quickly evolved beyond its planning.

Anyway, to bring my long winded answer to a close, its usually better to keep the compat getopt() behavior whenever possible. Code that gets instructions from the user is just the cost of doing business, so your concern should be fully on what makes for a better user experience, when possible.

Tim Post