| Subject: | Non option <> callback API breakage in 2.38 |
I've been bit by the slightly incompatible API change introduced in
2.38 of Getopt::Long which using objects of type Getopt::Long::CallBack
instead of strings for raw options.
Sample program showing the breakage:
=========================================
use Getopt::Long;
use Archive::Tar;
sub process_filename {
my $fname = shift;
print "Tar file: ", $fname, "\n";
my $next = Archive::Tar->iter( $fname );
while ( my $f = $next->() ) {
print "Tar member: ", $f->name, "\n";
}
}
GetOptions( "<>" => \&process_filename );
1;
=========================================
Output with Getopt::Long 2.37
=========================================
prog my.tar
Tar file: my.tar
Tar member: mymember
=========================================
Output with Getopt::Long 2.38
=========================================
Tar file: my.tar
Can't locate object method "read" via package "Getopt::Long::CallBack"
at <(...sitepath...)>/lib/5.12.1/Archive/Tar.pm line 318.
=========================================
What happens in this case is that Archive::Tar sees that the filename
is passed as an object and assumes that it is a virtual handle to the
file instead of trying to open the file. While in theory Archive::Tar
could probably check if the passed in name is a IO::Handle, this
assumption is not unique to Archive::Tar and seems to be common among
numerous modules that can accept either a filename or a file handle.
I've had a number of scripts break when using non-options callbacks to
collect filenames because of this difference.