Utterly BIZARRE behavior of IO::All vs glob

Discussion in 'Perl Misc' started by usenet@DavidFilmer.com, Jun 14, 2005.

  1. Guest

    This is the most bizarre thing I have ever encountered. I was able
    (with some difficulty) to figure out what was going on, but I still
    don't know why.

    Consider this simple example script which looks for files and adds them
    to a zip archive:

    #!/usr/bin/perl -w
    use IO::All;
    use Archive::Zip;
    use Digest::MD5 qw/md5_hex/;
    use strict;

    my $zip = Archive::Zip -> new();
    my $dir = '/my/path';
    my $item = 'ETN599827';

    foreach my $file(sort glob ("$dir/$item*")) {
    print "PROCESSING: '$file' - @{[md5_hex $file]}\n";
    $zip -> addFile($file , io($file)->filename )
    || warn "Could not add $file\n";
    }

    THAT WORKS FINE. There is a debugging statement which prints the
    filename and the filename's md5sum, which outputs thus:

    PROCESSING: '/my/path/ETN599827.txt' - 0d8572577b458ded778efd0d88c6cf05

    But I prefer the flexibility IO::All, and lately I've been using that
    module exclusively for my IO needs.

    So what happens when I replace the glob with an IO::All statement
    (one-line change):

    foreach my $file (io($dir)-> filter(sub {$_->name =~
    /$item.*/})->all_files) {
    print "PROCESSING: '$file' - @{[md5_hex $file]}\n";
    $zip -> addFile($file , io($file)->filename )
    || warn "Could not add $file\n";
    }

    Perl outputs thus:

    &Digest::MD5::md5_hex function called with reference argument at
    test.pl line 29.
    PROCESSING: '/my/path/ETN599827.txt' - 0d8572577b458ded778efd0d88c6cf05
    stat() on unopened filehandle GEN535 at
    ..../site_perl/5.8.4/Archive/Zip.pm line 2503.
    Could not add /my/path/ETN599827.txt

    The Digest::MD5 and Archive::Zip messages are courtesy of "-w" - they
    don't print if warnings are not enabled.

    The IO::All function SEEMS to be returning a plain, ordinary scalar
    value whose MD5SUM is IDENTICAL to the result from the glob. This
    debugging statement is returning the identical result:
    print "PROCESSING: '$file' - @{[md5_hex $file]}\n";
    But Perl seems to think it's some type of reference when it comes
    from IO::All.

    This is Perl 5.8.4 built on AIX 5.1 using IO::All 0.33

    I'm very interested to learn more about what is happening. Does
    anyone have any ideas or suggestions? Thanks!
    , Jun 14, 2005
    #1
    1. Advertising

  2. Also sprach :

    > But I prefer the flexibility IO::All, and lately I've been using that
    > module exclusively for my IO needs.
    >
    > So what happens when I replace the glob with an IO::All statement
    > (one-line change):
    >
    > foreach my $file (io($dir)-> filter(sub {$_->name =~
    > /$item.*/})->all_files) {
    > print "PROCESSING: '$file' - @{[md5_hex $file]}\n";
    > $zip -> addFile($file , io($file)->filename )
    > || warn "Could not add $file\n";
    > }
    >
    > Perl outputs thus:
    >
    > &Digest::MD5::md5_hex function called with reference argument at
    > test.pl line 29.
    > PROCESSING: '/my/path/ETN599827.txt' - 0d8572577b458ded778efd0d88c6cf05
    > stat() on unopened filehandle GEN535 at
    > .../site_perl/5.8.4/Archive/Zip.pm line 2503.
    > Could not add /my/path/ETN599827.txt
    >
    > The Digest::MD5 and Archive::Zip messages are courtesy of "-w" - they
    > don't print if warnings are not enabled.
    >
    > The IO::All function SEEMS to be returning a plain, ordinary scalar
    > value whose MD5SUM is IDENTICAL to the result from the glob. This
    > debugging statement is returning the identical result:
    > print "PROCESSING: '$file' - @{[md5_hex $file]}\n";
    > But Perl seems to think it's some type of reference when it comes
    > from IO::All.


    My suspicion is that IO::All returns objects with overloaded
    stringification. Digest::MD5::md5_hex checks whether its argument is an
    object and, in case its not an instance of Digest::MD5, barfs.

    I am not really surprised that modules such as IO::All which
    incorporates every conceivable seemingly smart trickery would sooner or
    later exhibit strange interaction with other modules. That's the price
    you have to pay if you prefer laziness over robustness.

    Tassilo
    --
    use bigint;
    $n=71423350343770280161397026330337371139054411854220053437565440;
    $m=-8,;;$_=$n&(0xff)<<$m,,$_>>=$m,,print+chr,,while(($m+=8)<=200);
    Tassilo v. Parseval, Jun 14, 2005
    #2
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Georgy Pruss
    Replies:
    15
    Views:
    712
    Tim Roberts
    Dec 1, 2003
  2. Tim Peters
    Replies:
    1
    Views:
    348
    Duncan Booth
    Dec 1, 2003
  3. Sean Berry

    Question about glob.glob <--newbie

    Sean Berry, May 4, 2004, in forum: Python
    Replies:
    3
    Views:
    340
    David M. Cooke
    May 4, 2004
  4. Elbert Lev

    glob.glob unicode bug or feature

    Elbert Lev, Jul 31, 2004, in forum: Python
    Replies:
    5
    Views:
    382
    Neil Hodgson
    Aug 2, 2004
  5. Replies:
    0
    Views:
    103
Loading...

Share This Page