Thread: Options and argument order in cli programs.

Hello folks, bit of an odd question here. As far as I know Unix convention normally dictates that each program option that takes an argument should immediately be followed by that argument, e.g

Code:

ping -a -c 2 -i 0.5

Many usage cases correctly display this pattern [options [option argument]] [program arguments] yet many do not; opting instead for something like:

Code:

usage: program [options] [program arguments]

which isn’t entirely accurate. I realize this probably has to do with the manner in which the getopt function operates, or perhaps getopt was made to work in this manner to adhere to the established convention. Now, for better or for worse, I had to make my own getopt equivalent long ago, before I knew about this unspoken convention, and when faced with this “style” dilemma, I decided to go in another direction: Instead of

Code:

./a.out -a bar -b foo

I have

Code:

 ./a.out -a -b bar foo # or ./a.out -ab bar foo

or going back to my first example:

Code:

ping -aci 2  0.5

I admit I went with this style in no small part because I favor the grouped options -abc much better than -a -b -c. And it felt natural and more consistent to do it that way. Recently, when reviewing a program I made, someone criticized my decision claiming it was awkward and confusing to run the program. I disagree, but now Im curious to hear what others think. Do you have any valid criticism against my approach? Thanks.

Thank you guys for the feedback.

Although Salem brings some valid technical points, which I’ll touch later, it seems most of the issues you raise pertain to clarity and readability. After much deliberation, I have to concede on this point.

To me, the approach is no more complicated than the established way, and it has a certain appeal from an organizational point of view. Yet this is exactly the problem; one does not write code for oneself, but for others to read. Similarly, one writes a program for others to use, and if a design choice makes this goal harder, then it is the wrong choice.

This reminds me of a guy I knew who refused to indent his code. He would write huge squared blocks like:

Code:

var = functioncall();
if (var == value)
do something
else dosomethingother()
otherfunctioncall()

which he claimed was aesthetically pleasing and helped him understand his code better.
I felt silly thinking I’m sort of doing the same here.


Salem,
The idea is the program arguments would come first, then the options and anything after would be option arguments; the order in which they appear indicating the option they belong to.

Code:

 program [program arguments] -option1 -option2 -option3 optarg1 optarg2 optarg3

If we want to omit option2’s argument, we would need to change the position:

Code:

 program [program arguments] -option1 -option3 -option2 optarg1 optarg3

But as you notice, things can get unruly when the number of options increases, even I have to admit that.

Your approach is actually harder to use in the case of creating a program to drive your program.Instead of incrementally adding flag value flag value to an argv, I would have to maintain a separate list of values to append to argv, once I'd finished adding flags.

Very valid point.

I'm curious as to how you handle filenames which begin with a minus.

I actually hadn’t thought of that, why would anyone put minus at the beginning of a file is beyond me, but it is a legal character so I guess it could happen.