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'))
{
[download]

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
[download]

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
[download]

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.
[download]

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.
[download]

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.