Use POPT for CLI option processing and --help

[GoogleCodeExporter]

The attached patch uses POPT to process skipfish options.

There's a couple of benefits (but otherwise its just option processing *shrug)

1) POPT is table driven (which is often easier to maintain). E.g. long
--options can be added merely by filling in the table entries

2) POPT aliases can be used to shorten option sets. E.g. something like
this in ~/.poptrc or /etc/popt:
    skipfish alias --myopts -Y -r 1000
permits an invocation like
    ./skipfish --myopts -o xxx http://example.com
Note: There are POPT exec's (which end up invoking other commands) but
I did not bother to turn them on.

3) POPT has support for i18n and --help and -? (short form --help) and
all the usual facilities that a CLI option processor library is expected to
perform.

And my ulterior motive for changing skipfish option processing

4) popt-1.16 includes methods for Bloom filters and popt-2.0 will have
support for KEY=VAL hash table mappings shortly. That is (in fct)
why I bothered with POPT->skipfish is to do the "mapping" development
(I maintain POPT).

You can find a copy of popt-1.16.tar.gz at
    http://rpm5.org/files/popt
if you wish to embed POPT in skipfish for "portability". Otherwise
POPT is quite commonly used.

I've tried hard to preserve _EXACTLY_ your CLI option semantics and aesthetics,
but I've likely done some damage somewhere somehow. Caveat emptor.

Original issue reported on code.google.com by n3npq....@gmail.com on 7 Jul 2010 at 2:25

Attachments:

• skipfish.c.patch

[GoogleCodeExporter]

Thanks for the awesome patch. We have long options in the current version which 
I think obsoletes this patch ;-/  (although the features are not the same).  Do 
you think we should still switch? 

Niels

ps: I'll reply with < 1 year ;p

Original comment by niels.he...@gmail.com on 3 Aug 2012 at 1:22

• Added labels: Priority-Low, Type-Enhancement
• Removed labels: Priority-Medium, Type-Defect

[GoogleCodeExporter]

I think you should stillk switch: yes. I'll be happy to update the patch
to handle any newly added long options in POPT tables if you wish,
and to finish KEY=VAL through a hash table implementation within POPT.
(Bloom filters turned out to be mostly enough for opaque keyword
existence/logic tests passed from the CLI).

I'm not sure why current long options intrinsically obsoletes this
patch (other than bit rot since the patch was written).

CLI option processing is highly idiosyncratic however. I find POPT tables
a compact means to represent/maintain large/complex option sets but
YMMV.

Do you want an updated patch?

Original comment by n3npq....@gmail.com on 3 Aug 2012 at 2:31

[GoogleCodeExporter]

It would be great if you are willing to update the patch! Perhaps this can wait 
until the next version is out ? (there are a ton of changes and I plan to get 
it out next week).

Portability is a point of attention but popt is available for all platforms so 
if I either update the instructions (or even include the package) than this 
will work fine.

Thanks!

Original comment by niels.he...@gmail.com on 7 Aug 2012 at 11:42

• Added labels: OpSys-All, Usability

[GoogleCodeExporter]

I - devzero2000 or yersinia.spiros - am also a - lazy - comantainer of popt - 
and rpm5 FWIW - thanks to jeff Johnson. We have interest in skipfish also for 
our project. When i have some time on this - and if jbj don't already post a 
patch . i will try also. JFI, If you like popt or have any questions this days 
we @rpm5.org have the bugzilla and the blueprints on lauchpad 
https://code.launchpad.net/popt

Original comment by pinto.e...@gmail.com on 12 Aug 2012 at 1:05