1

When using a utility program, we may specify options (and their option arguments) and/or operands.

In most cases (in the sense of conforming to some standard (POSIX?))

  • does the order between options not matter?
  • does the order between operands matter? (e.g. the operands of find are ordered, so are grep)
  • does the order between options and operands matter? (e.g. ls . -l and rm mydir -r are said to be not POSIX compatible.)
  • if an option can optionally have an option argument, how can the program know if something following the option is the option's argument or an operand?

Btw, do the standard argument parsing library in C (e.g. getopt), and in Python (e.g. argparse) conform to the same standard for options and operands?

C.f.http://pubs.opengroup.org/stage7tc1/basedefs/V1_chap12.html

Community
  • 1
Tim
  • 101,790
  • Does the order between operands matter?  I guess it depends on the program. ls foo bar and ls bar foo are equivalent.  What about cp foo bar and cp bar foo — what do you think? – Scott - Слава Україні Apr 01 '15 at 13:46
  • What does http://pubs.opengroup.org/stage7tc1/basedefs/V1_chap12.html think? – Tim Apr 01 '15 at 14:20
  • I would encourage you to try harder to figure things out for yourself before you ask questions.  It took me about five seconds to find Guideline 12: The order of operands may matter and position-related interpretations should be determined on a utility-specific basis. – Scott - Слава Україні Apr 01 '15 at 18:09

1 Answers1

2

Well, the Utility Sintax Guideline can answer your question about the order of the options, and it's relationship with other options:

Guideline 11:

The order of different options relative to one another should not matter, unless the options are documented as mutually-exclusive and such an option is documented to override any incompatible options preceding it. If an option that has option-arguments is repeated, the option and option-argument combinations should be interpreted in the order specified on the command line.

The only place where ordering those is important is on documentation:

  1. Options are usually listed in alphabetical order unless this would make the utility description more confusing. There are no implied relationships between the options based upon the order in which they appear, unless otherwise stated in the OPTIONS section, or unless the exception in Guideline 11 of Utility Syntax Guidelines applies. If an option that does not have option-arguments is repeated, the results are undefined, unless otherwise stated.

However, if you have a command where an argument does not need an option, and another that does, you can group with only one - symbol, since the argument with options comes after the one who doesn't:

Guideline 5:

One or more options without option-arguments, followed by at most one option that takes an option-argument, should be accepted when grouped behind one '-' delimiter.

Since POSIX is a standard, it's up to the programmers of a technology to make it compliant or not, and how to handle option_arguments. You could make a non-POSIX argparse Python program with the following code:

>>> parser = argparse.ArgumentParser(prog='PROG', prefix_chars='-+')
>>> parser.add_argument('+f')
>>> parser.add_argument('++bar')

This way, your program arguments will start with +, not being POSIX when confronted with Guideline 4:

Guideline 4:

All options should be preceded by the '-' delimiter character.

And about ordering, is just a matter of using the .parse_args() function to decide where your arguments will be pinned to a position. To argparse lib, there is no operand. Everything is an argument. An operand here is just an argument without the - character, and again, is up to the programmer decide if the software being made will be POSIX compilant or not.

If implemented on the right way, argparse is itself POSIX compliant. Suggested reading:

  • argparse – Command line option and argument parsing

Related Stuff:

Community
  • 1