in reply to Re: Detecting an undefined hash key
in thread Detecting an undefined hash key

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.

Replies are listed 'Best First'.
Re^3: Detecting an undefined hash key
by toolic (Bishop) on Oct 01, 2008 at 19:21 UTC
    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.
[reply]
[d/l]
[select]

      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

      Read more... (1189 Bytes)

      and

      Read more... (1169 Bytes)

      -s and -t appear to be hungry in getopt

[reply]
[d/l]
[select]
        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.

[reply]
[d/l]

In Section Seekers of Perl Wisdom