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

my ($hello,$goodbye); # option switches
GetOptions (
    "hello"  => \$hello,
    "goodbye" => \$goodbye,
);

if ($hello) {
   print "Hello world\n";
}

if ($goodbye) {
    print "Goodbye!\n";
}
[download]

# use full options
> perl test.pl --hello --goodbye
Hello world
Goodbye!
[download]

# use abbreviation 
> perl test.pl -h
Hello world
[download]

Getopt::Long can also handle a variety of different option types, with or without arguments etc. See the documentation.

You guys are the best - that worked! Thanks!

One more quick question, how do I set it so that an argument is required? Right now I have:

my ($read,$generate,$help); # option switches
GetOptions (
    "help" => \$help,        
    "read"  => \$read,
    "generate" => \$generate,
);
[download]


If I run the it with any switch, it works perfectly - run it with no arguments, it does nothing at all. :) I'd like to add one more switch for a blank variable, so I can toss in a string that says "type -help for usage'."

Thanks very much as always!

I usually start scripts that require arguments with

die "Usage message\n" unless @ARGV;
[download]

Make sure you put that before the call to GetOptions (it modifies @ARGV)
"What should it profit a man, if he should win a flame war, yet lose his cool?"

how about:

my ($read,$generate,$help); # option switches
GetOptions (
    "help" => \$help,        
    "read"  => \$read,
    "generate" => \$generate,
);

die "$Usage\n" unless $read || $generate;
[download]

Paul

An easy, cheesy, but very workable way, would be to use a big if statement.

if($command_line_switch =~ /hello/) {
  # program 1 code
}

if($command_line_switch =~ /goodbye/) {
  # program 2 code
}
[download]

NOTE:

I'm assuming that you already know how to process command line switches.

Very near the top of each of your two scripts, put the following code:

use strict;
if (! caller) {
    main();
    exit 0;
}
sub main {

    # leave some room here.

}
[download]

Now, when you run your scripts they will do nothing. Pull in things from the file-level into this new main sub you've created, until each script works exactly as it had worked before (it helps if you already have some regression tests).

Then, when doing the actual merge, put the code that selects either run mode before this new main (which now you have to call main_script1 and main_script2, only please use better names instead). Put it right there in the if statement, instead of the call to main.

The purpose of this whole exercise is to keep yourself from forgetting stray code that might have been hiding between subs, and if you hadn't been using strict, prevent global variables that had the same name from each script from interfereing with each other.

This is really modest advice; but it helps to force you to do cleanups on one front at a time, if they turn out necessary. Of course maybe your code is already squeaky clean and you don't need all this :)

Here is a snippet using Getopt::Long. You can call the script with a "--run_script" argument (or just "-r"-- Getopt::Long accepts unique abbreviations for flags). You could put an if block after the print statement to control which code, depending on the value of $pars{run_script}:

#!/usr/bin/perl

use warnings;
use strict;

use Getopt::Long;

my %pars = ( run_script => 0 );
GetOptions (
    \%pars,
    'run_script=f',
);

print "Run script $pars{run_script}\n";

allen94-lt 11: ./getopt_ex.pl -r 5
Run script 5
allen94-lt 12: ./getopt_ex.pl 
Run script 0
[download]

Note the default value (0) that run_script has been given in the creation of the %pars hash. You could change this by changing the original setup of the hash.

--Kester

A solution (although it migh be a BadIdea and misguided would be)

### in hello.pl
print "Hello";

### in goodbye.pl
print "goodbye";

### in choose.pl
require shift() . ".pl";
[download]

Then fromt he command line perl choose.pl hello would run the hello code, and the same for goodbye. You should definitly verify that the input is a real file that you want to allow them to run etc., but this should get you started down this path. In general i would think it is a bad idea and would rethink what you are doing to see if it fits in some differen t model better.