Seeking Getopt recommendations - anyone used Getopt::Easy?

[theguvnor]

Hi. I've started to get tired of parsing my own command-line arguments to my programs at work, but don't think I want to go for anything too heavy/complex (Getopt::Long seems to get a lot of "play" but the interface seems a bit peculiar to me).

Does anyone have anything to say about Getopt::Easy (good or bad)? It seems to be simpler than the aforementioned Getopt::Long, but have the monks found any reasons to avoid it?

Thanks

PS and I did check both SuperSearch on this site, and AnnoCPAN, and found nothing.

Update: thanks to the three monks that have given me their feedback! Still hoping for more though... :)

[gaal]

I've never used Getopt::Easy so I won't comment on that. But here's the idiom I use for Getopt::Long. I'm so used to it I don't have to think--easy enough for me!

GetOptions \our %Cmdline, qw(input|i=s output|o=s foo=i bar:i baz);

To tell the truth "=s" is the only spec I really use nine times out of ten :)

The nice thing about this is that I get a global with convenient longnames that are the same as the longnames on the command line: $Cmdline{input} etc.

Sure, there's a lot missing here. This doesn't wire into the POD of my script, and it doesn't generate --usage notes. And those are tedious to write and there are "better" modules out there. They aren't core, though, and some have other disadvantages, so for casual programming with Perl 5, I stick to Getopt::Long.

Recently in a larger project I've used App::CLI (although App::Cmd seems similar yet more featureful, I had deployment issues with it). YMMV.


ObPerl6: in Perl 6, this is so much better :) The entry point to your program is always a subroutine called MAIN, and get this, the signature (Perl 6 has function signatures) captures the command line arguments for you (Perl 6 has function signatures powerful enough to express almost anything you'd care to spec on the command line). Nifty!

[BaldPenguin]

I haven't used Getopt::Easy but from the docs it appears to just limit the config and options to a subset of what Getopt::Long can do. With that I can offer this advice.

I tend to use the same things over and over again, like Getopt::Long. Sometimes all I need is a -h for a help screen, other times it gets more complicated. Using the same libraries over time allows me to go into old scripts and change some parameters around. Using scaled down versions can strip me of some flexibility. Sometimes you need to worry about footprint and the scaled down versions are the best way to reduce program size.

Another blind comment, not having looked at source code, be careful to not include a library just because of the simpler API, they can just be frontends to the same large backend. In that case it's just as good to learn the more 'peculiar' interface and keep your options down the road open.

[ides]

I agree with what's been said here. I too haven't used Getopt::Easy, but use Getopt::Long all of the time. The main reason to not use Getopt::Easy that I can see would be that it isn't a CORE module and would need to be installed on every machine where it is used.

While we're sharing coding idioms.... here is what I always do for commandline arguments:

use strict; 
use Getopt::Long; 

# Main body 
eval { 
     my $options = { 
                      'help'       => 0, 
                      'verbose'    => 0, 
                      'config'     => '/etc/myapp.conf',
     }; 

     GetOptions( 
                      'help'       => \$$options{help},
                      'verbose!'   => \$$options{verbose},
                      'config=s'   => \$$options{config},
     ); 

}; 
print "ERROR: $@" if $@;

This lets you set defaults for your options and GetOptions() handles any commandline overrides by the user.

[gaal]

What's the purpose of eval { ... }; print ... if $@?

It's almost always better to let the program die if it received invalid input. You'll get the same error message (without the "ERROR: " prefix) on standard error.

[ides]

Sorry I should have been more clear. I use that standard setup and include all of the program's logic in the eval, just after the GetOptions() call. I do this in case I want to trap out the error and do something more special with it later.