Llew_Llaw_Gyffes has asked for the wisdom of the Perl Monks concerning the following question:

I have a Perl script which begins as follows:

#!/usr/bin/perl use strict; use Getopt::Long; my (%opt); Getopt::Long::Configure ("bundling"); if (GetOptions(\%opt, 'digits=i', 'help|usage|?', 'quiet', 'reverse', 'separator=s', 'test|n', 'verbose', 'zero|0')) {

In this script, and ONLY this script, Getopt::Long fails.  In every other script I have, it's working perfectly.  Invoking the above script with a sample command line yields:

babylon5:alaric:/minbar/camera/canon/test:39 $ renum -t foo img* Unknown option: t

I'm baffled.  I've rewritten the entire top of the file by hand in case somehow the file has become corrupted with some invisible character.  I can see nothing wrong with it, but I can't make it work, and no other Getopt::Long-using script on my system breaks the same way.  If I remove the call to Getopt::Long::Configure, the GetOptions call recognizes options again, but of course option bundling no longer works.  If I write a new script from scratch comprising nothing but a call to Getopt::Long and the necessary declarations, it fails in the same way; yet every other existing script using Getopt::Long and Getopt::Long::Configure("bundling") continues to work.

Can anyone some up with any theory, however wild, to explain what's going on, or point out some error in the code that I've somehow missed?


It was not clear from the example above that ALL options are unrecognized, not just -t.  To clarify, if I comment out the bundling configuration, I can do the following:

babylon5:alaric:~:1 $ renum -t -d 4 foo bar* Test mode: No changes will be committed Trying pattern: bar\* Using format foo-%04d.jpg No files found; doing nothing

Now, if I re-enable the Configure call and issue the exact same command:

babylon5:alaric:~:2 $ renum -t -d 4 -r foo bar* Unknown option: t Unknown option: d Unknown option: r Usage: renum [options] pattern files Options: -d digits Use <digits> digits in ordinal field -zero, -0 Begin numbering from 0 (default 1) -quiet Quiet (no progress messages) -reverse Reverse order -separator <char> Use <char> as separator character (default +'-') -test, -n Do not make any actual changes All options may be abbreviated.

In subsequent messing with this, I've discovered that I can make it recognize the command line options again by explicitly specifying the appreviations I want to be accepted.  It is possible I have misunderstood the documentation on the module.  The documentation states:

Without additional configuration, GetOptions() will ignore the case of option names, and allow the options to be abbreviated to uniqueness.

Now, the interaction between bundling and ignore-case is documented, but NOWHERE IS IT SPECIFICALLY STATED that setting any particular configuration option (bundling, for example) disables the automatic abbreviation.  It appears, however, with further examination, that this is what's happening:  if bundling is enabled, automatic abbreviation of command-line options is silently disabled.  What's more, there appears to be no mechanism for re-enabling it.

Can anyone confirm that this behavior is in fact intentional?  If so, it really should be documented.