[getopt-sig] Option package requirements

[Matthias Urlichs]

Having browsed the archives a bit, I'm now going to put my foot in the
door (probably while somebody else tries to close it ;-) and chime in
with my own option package requirements:

- Modules should be able to add their own options without requiring
  modification of the main program (so there should be a single default
  option-parser object which is instanciated only once).

- Options and help strings should be declared ONCE, in ONE place.
  If that means extra work for the option parser when it has to actually
  display the help text, so be it.

That pretty much rules out anything but Optick at this point. ;-)


To justify the following more-or-less esoteric requirements (which
arguably should go to the Optick list :-): 

IMHO it's of no use at all to specify an option processing package which
ends up being unable to handle real-world requirements. Real programs have
a whole bunch of usages, and I want my Python program to be able to
emulate those other programs.

- Positional vs. global options. Suppose I want to rewrite
  sox, the command-line sound converter. It has this Usage string:
  
  sox [ gopts ] [ fopts ] ifile [ fopts ] ofile [ effect [ effopts ] ]

  This might boil down to an Optik call like
  
  parser.add_option(1, ...)

  meaning that this "option" is processed for the first non-option argument.
  (In this case, a callback function would stash the input file's fopts
  someplace safe so that they're not overwritten by the output file's
  fopts.)

- A way to end option processing / gobble up all remaining arguments.

  Suppose I want to rewrite ssh. It haas this option:

  ssh HOST foo ...

  which calls the remote "foo" program with any options given afterwards.
  (Enclosing these options in a string, like "sh -c" wants me to, is NOT
  the Right Way.)

  Note: This example would add the end-processing option to the 'option'
  2. Other programs use "-e" or "--exec" for this. Same thing, if
  the above option is implemented.
  
- Freely mix options and arguments.

  See any GNU Makefile; they end up calling "makeinfo FOO.texi -o FOO.info".

- Shorthand arguments.

  Suppose I want to rewrite gpg. It allows me to shorten long option names
  as long as they're unambiguous, so "--output-file" can be written
  "--output-f".

- Optional option arguments.

  Suppose I want to rewrite the GCC front-end. See, for example, its "-g"
  and "-O" options.

  gcc file       -- no -O given
  gcc -O file    -- -O without value
  gcc -O1 file   -- -O with value
  gcc -O 1 file  -- process the two files "1" and "file".

  Long options should work likewise:

  gcc --opt file    -- -O without value
  gcc --opt= file   -- -O with empty value (impossible with short options)
  gcc --opt=1 file   -- -O with value

  Another example for this is the mysql client program (the "-p" option).

-- 
Matthias Urlichs     |     noris network AG     |     http://smurf.noris.de/
-- 
No experiment is ever a complete failure, inasmuch as a well-written
account of it can serve admirably as a bad example.