optparse functionality missing

[Jeff Keasler]

Hi,

optparse doesn't seem to have a pass-through capability for command line
parameters/options that were not registered with add_option.

I'm not the first person to complain about this. On Wed Mar 17 08:20:10 CET
2004, there's a thread titled "Perceived optparse shortcomings" where someone
complains of the same problem.

In a scripting environment, I often want to strip some of the command line
options off the argument list, and then pass the remaining options to another
module that is deeper in the tool chain.

optparse doesn't seem to allow this, as far as I can tell. It requires that
you register all possible options with add_option() or an error is flagged.
When my second tier module is an autoconf script that could have hundreds of
its own options, it seems dumb to have to register all those options, just to
have to reconvert them to command-line options so that I can pass them to the
autoconf command line.

Could we get a mode added to optparse so that any commandline
parameters/options that are not registered via add_option() can be in the args
return value of the parse_args() method?

-Jeff

[Mark Wooding]

Re: optparse functionality missing

Jeff Keasler <keasler@llnl.g ovwrote:

In a scripting environment, I often want to strip some of the command
line options off the argument list, and then pass the remaining
options to another module that is deeper in the tool chain.

The difficulty is that you can't do an accurate parse without knowing
which options take arguments. For example, what are the options here?

foo -xyzzy -abcdef -ghi -ghi -g -hi

Well, `-z', `-f' and `-g' take arguments; the `-g' argument is
optional. So the correct options to pass along are

-x -y -zzy -a -b -c -d -e -f-ghi -ghi -g -h -i

Not so obvious, is it? ;-)

-- [mdw]