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

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!

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 $@;
[download]

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

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.

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.

Frank Wiles <frank@revsys.com>
www.revsys.com