toolic, thank you for taking the time on this.

I did cut and paste your code and uncommented the usage of Data Dumper to see what was happening.

Using -t, I get

./714799.pl -t
opt $VAR1 = {
          't' => undef
        };
neither -t or -s used
[download]

with similar results for a singular -s.

Observe the test to see if either option had been specified fails.

Using both -s and -t I get

./714799.pl -s -t
opt $VAR1 = {
          's' => '-t'
        };
either -t or -s used
[download]

Using -a -b gives

./714799.pl -a -b
opt $VAR1 = {
          'a' => 1,
          'b' => 1
        };
neither -t or -s used
[download]

and singletons of either give one hash element with the value one.

So I still feel there is something strange about at least s and t as options for getopt.

I read the documentation and saw that getopt and getopts appear to behave differently.

It is mea culpa because the documentation clearly states getopt expects each switch to have an argument. Therefore -s -t should interpret -t as the argument to the -s switch (and vice versa).

Except this doesn't appear to hold if one uses -a -b. Here the default value of 1 is used for both.

I may try checking the rest of the alphabet on this one

The end result is the getopts function behaves the way I originally expected getopt to behave

Thank you once again for taking the time on this

Update

and

-s and -t appear to be hungry in getopt

OK, again:

There only is "something strange" about s and t, because you tell getopt to read values for these switches, calling it getopt('st'). The parameter for getopt doesn't contain "allowed" switches, it contains switches that expect an argument.

If you don't need values for these switches (which seems to be the case) just don't name them in the first parameter to getopt. Getopt will still, when it stumbles upon that switch on the command line, define the hash entry for the given letter and give it a value of 1.

I'm a numpty

Thank you for being so patient