Take the 2-minute tour ×

I am doing some maintenance on a program that accepts command line options. There are a single letter options, as well as long options. Currently, the long options have a single preceding hyphen.

Many tools have double hyphens for their long options. Trying to be consistent with what's out there, I looked at some of the GNU tools, and saw that for the long form, there is a mix of single- and double-hyphens. For example, the GCC compiler has --help, --version versus -std, -funroll-loops.

So I searched for some documentation on the matter and found this GNU document. There, GNU's style recommendation for long options is to begin with two hyphens.

Now, I wonder why GNU tools don't follow these GNU recommendations? I assume that it is a matter of backward compatibility, but is there more to that?

In programs that I write, when changing the options syntax I usually leave the older form functional but undocumented, or at least give a deprecation warning. Is it not possible to do so for the GCC (and other) program(s)?

share|improve this question
Could it be the age of GCC? I think it predates most other GNU tools and probably the GNU conventions? –  Sean Dec 16 '12 at 8:06
@Sean - My bet is that this is the most probable reason, as I mentioned in the question. However, there are ways to update the tool w/o breaking backward compatibility. –  ysap Dec 16 '12 at 8:08
@ysap Actually you can't change it in a backward compatible way. gcc style long options would conflict with combined short options. e.g. -march=i386 == -m -a -r -c -h=i386 –  John5342 Dec 16 '12 at 8:28
@John5342 - what I mean is, add an option --march=i386 and remove -march from the documentation only. –  ysap Dec 16 '12 at 8:33
@ysap You can remove it from documentation but you would still have to keep the actual option around for a long time so you still can't use the short options. You would just end up providing two ways to pass the same parameters forever. –  John5342 Dec 16 '12 at 16:37
add comment

1 Answer

There are plenty of reasons not to change:

  • There are quite literally millions (probably many more?) of configuration scripts and build files that use the existing command line options. Both recent and very old.
  • People are used to the current format so most programmers for many years will just use what they already know out of habit.
  • Argument parsing code is often complicated and changing it is just another opportunity for introducing bugs.
  • The old backward compatibility single hyphen long options would conflict with the new multiple short options combined so backwards compatibility is difficult.
  • Insert many more here.

Reasons to change:

  • To follow convention that is already not followed by many applications.

In short convention is nice and should ideally be followed for new stuff but often it is not worth changing stuff just for the sake of conformity.

share|improve this answer
John, please see my reply to your comment above. –  ysap Dec 16 '12 at 8:35
..although I can see the possible problem - if the older form is removed from documentation, then one could assume -march is a valid combination of 5 short options. –  ysap Dec 16 '12 at 8:37
@ysap Even if you remove -march only from the documentation you would still have to keep -march as a valid option more or less forever for the millions of existing uses. The only advantage of the '--' and '-' options is that you can combine multiple short options into one. Since you still can't combine short options to avoid interfering with the backward compatible options there would be no benefit to changing things. If gcc did not have all these other scripts etc using it then it would of course be another story since there would be much less to change. –  John5342 Dec 16 '12 at 16:34
add comment

Your Answer


