Re^2: Detecting an undefined hash key

[LesleyB]

Wow, wow and double wow

It would seem that s and t are indeed strange in Getopt::Std.

There is much for my simple mind to digest in all these replies and I thank you all for the tips and nudges on exists and Data::Dumper

I did think that, if one expected to use -t <value> on the command line then the expected syntax for getopt would be getopt('st:',\%opt); with the : indicating a required value for the argument.

I'll have to check the documentation on that but this did mean I thought the lack of a : would make it clear no value was being supplied for aither the s or t arguments.

[toolic]

It would seem that s and t are indeed strange in Getopt::Std.

I disagree. There is no evidence which supports the claim that s and t are strange in any way. I tried using a and b instead of s and t in my example, and the behavior is the same. Give it a try.

I did think that, if one expected to use -t <value> on the command line then the expected syntax for getopt would be getopt('st:',\%opt); with the : indicating a required value for the argument.

The getopts function (notice the "s" on the end) uses the ":" syntax, not the getopt function. So, it seems that, contrary to the docs, getopts requires you to supply a <value> with each switch.

[LesleyB]

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

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

Using -a -b gives

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

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

Read more... (1189 Bytes)

and

Read more... (1169 Bytes)

-s and -t appear to be hungry in getopt

[pjotrik]

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.