Re: check parameters

[blue_cowdawg]

Why not just use Getopt::Long? Sample:

#!/usr/bin/perl -w 
use strict;
use Getopt::Long;

my $abc = 1;
my $bar=1;
my $fii=1;
my $wee=1;

my $result = GetOptions("abc=i" => \$abc,
                        "bar=i" => \$bar,
                        "fii=i" => \$fii,
                        "wee=i" => \$wee
             );

| etc...

If I remember correctly (can't remember what I had for breakfast and I have the same thing every day) Getopt::Long is part of CORE and therefore you need to load it on your system.

[ag4ve]

I am using Getopts::Long. This is:

GetOptions( param|p=s@   => \$opts->{params} );

What I presented was a test showing where I am failing.

[blue_cowdawg]

I am using Getopts::Long. This is:

Didn't notice that in the code you presented.

I'm not sure what is failing in your code or why. What were you expecting? Seems to me you could accomplish what you are trying to do with much more readable code.

If I'm trying to test for the presence of a command line parameter I normally set the variables to something null and test later to see if they've been set. Here's an example:

| handwaving
my $result = GetOptions( 'file=s' => \$infile,
                         'debug' => \$debug,
                         'verbose' => \$verbose,
                         'out=s' => \$outfile
              );

upchuck_and_die unless ( $file && $outfile ) ;

|
| stuff
| later on
sub upchuck_and_die {
     print "you must specify --infile=<file> and --outfile=<otherfile>
+\n";
     exit(-1);
}

You could do the same thing with a hashref but I like the readability of using discrete variables instead.

“Let us redefine progress to mean that just because we can do a thing, it does not necessarily mean we must do that thing.” – Federation President, Star Trek VI