I am answering a bit of a different question than what you asked because I'm not sure what you are really trying to do?

I would suggest before launching off into one of the more complex modules and its implementation of Getopt::Long, that you play around with and learn the basics of how to use the Std version of Getopt (one option letter) - that's the way that thousands of unix programs have been written and you can go a long way with this!

I personally haven't needed the long version of getopts yet. "Yet" doesn't mean never will need it, it just means not yet.

I don't know how much you know about what the purpose of these things are. I'll summarize perhaps as useful info for others:
1. Parse the @ARGV list (I guess that's obvious!)
2. Identify problems with the comand line grammar. A missing parameter or an invalid option.
3. Put the option and its optional arg into a structure that is easy for the program to use
4. Remove everything that it knows about from @ARGV! There can be things on the command line that are not options! After getopts is finished @ARGV will have what is left over. Maybe its a regex pattern, or some filename that has to be there or whatever. The important part is that the getopts thing will remove the stuff that it knows about which simplifies whatever you have to do with what is left in @ARGV. This perhaps is one of the most important parts about what these getopts things do!

Ok, so here some simple code for a hypothetical DB application. The important parts for the program:
1. check that getopts has no error (it will have an error if an illegal option is found)
2. check that the number of things left in @ARGV is what you expect. In code below it is zero.
3. check that the number of options is consistent with what you expect, here only one option is allowed.
4. if there is the possibility of inconsistent options, check that too! Maybe we can't add and delete at the same time or whatever!

In the below, getopts takes a "grammar" statement which says that -a and -s have to be followed by a parameter and that -l (the list option) takes no parameter. If there is say a "-x", getopts will return false. So we check the return value. Next we see if what has happened to @ARGV is what we expected. In this case, nothing should be in the list. Then we check if the number of options is what we expected. In this case, I only allowed one option at a time as this is a simple example. If there are incompatible options, say -x and -y, then you should check that the aren't both present. BTW, if -l doesn't take a parm, $opts{l} = 1.

It is possible to build what I would call "dispatch tables", that call subs based upon some list of "list of things to do". All of that is a separate discussion from getopts(). There are very good reasons to do that(and I have programs that do exactly that - great for GUI I/F where the user can select a whole bunch of things, but might not understand what the interaction is going to be). But you shouldn't be worried about some few "if" statements! Performance of an "if" statement is so fast that this doesn't matter below.

use Getopt::Std;

my %opts;
die "Usage: $0 -a file | -s state | -l\n".
    "-a adds to database (or create), -s lists state  -l lists whole D
+B\n"
    if (!getopts("a:s:l", \%opts) || @ARGV !=0 || keys %opts !=1; 
    
Add()         if $opts{a};
ListState()   if $opts{s};
ListAll()     if $opts{l};

sub ListState
{
   ...use $opts{s} here, the state name....
}
[download]