librarat has asked for the wisdom of the Perl Monks concerning the following question:

Hello monks!

I'm working with Longops on a project, but given the sheer number of options in the code I'm writing, I've managed to get myself confused. Seen in the snippet below is a sample of "options", each one acting a little different.

'add-domain|ad=s', # Add a domain. -n and -t are optional -ad 'do +main.com' -n 'Note like this' -t

This action can either be called with "-ad", "-ad -n", or "-ad -n -t", or "-ad -t" (each one obviously having a value). "-ad" is the actual action, -t and -n are supplementary to -ad.

'show-domains|sd', # Show all domains and their IDs -sd

The above action can only be called with "-sd". It takes no value (its a bool)

My question, and I guess my confusion, too is in the best way to go about getting parameters, sanitizing them, and validating their ability to go together. There are a total of about 30 different (and unique) options, some taking a value, some that are just bools.

Currently, I'm using a hash via GetOptions (\%options, and am just looking for values.

Cheers!

Libby

Replies are listed 'Best First'.
Re: Getopt::Long via. Hashes
by vsespb (Chaplain) on May 26, 2013 at 18:07 UTC

    I had similar question, so I re-invented the wheel and wrote my own GetOpts wrapper

    app code library code tests more tests

    (you can use it if you want to and capable to understand how it works, it's GPLv3. or maybe some day i'll release it on CPAN with product quality and documentation)

    Basically I verify options and option combination using plain 'if/else' code, but in separate 'layer' (before program execution), so when program start main work it has already all options validated and possibly reorganized.

    And I have DSL to for easier validation layer implementation for easier options definitions

    Also the library manages error/warning messages and helps to write unit test for options behaviour with ease

    Also you can try to reorganize your command line API and discinct options, commands, positional parameters, and script name aliases. That way complex options will look more sane

    Example:

    myapp-recaulculate.pl full-recalculate myfile --fast --ignore-errors
    instead of
    myapp.pl --reculculate --use-full-recalculate --file myfile --fast --i +gnore-errors.
    Also, I believe there is more than 100 CPAN modules, related to options processing. You can try to find one that fits your need.

      Thanks for the code! I half expected a reply such as that - I wound up doing the same thing actually. It's all basic IF/ELSE essentially.

      Cheers!

        Yep, but main thing - separate IF/ELSE from main logic, and don't hesitate to write helper functions for yourself to make IF/ELSE/definitions/error handling easier.

        Also, test your logic with unit tests to prevent regressions!

Re: Getopt::Long via. Hashes
by karlgoethebier (Abbot) on May 26, 2013 at 19:53 UTC
    «There are a total of about 30 different (and unique) options, some taking a value, some that are just bools.»

    Perhaps you should consider to use a config file instead of using so many options on the command line?

    Ok, there is a lot of stuff that uses so many options on the command line (e.g. tools for processing audio, video and graphics a.s.o) but IMHO this isn't really fun.

    Please take a look at Config::Tiny, XML::Simple and all that related stuff.

    Best regards, Karl

    «The Crux of the Biscuit is the Apostrophe»

      That would introduce same problems - you have lot's of options as hash, and not sure how to process them...

      Also some application prefer to allow any option to be used in config or in command line

        Also some application prefer to allow any option to be used in config or in command line

        Are there any fine exemplars of exactly this kind of Perl program on PerlMonks? I've been looking for a well-written Perl program that demonstrates the best way to use either a core module or a battle-tested CPAN module to permit the user to specify many arguments to the program either on the command line or in a config file—whichever she prefers.

        Jim

Re: Getopt::Long via. Hashes
by Anonymous Monk on May 27, 2013 at 07:42 UTC