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

I'm writing a CGI script on Win32 that needs to borrow a module from a different installation of Perl. The module I need (XML::XPath) is on a network drive, so I'm using code like this: 
use lib "\\\\otherbox\\path\\to\\site\\lib";
use XML::XPath;
use XML::XPath::XMLParser;

[download]
This sort-of works -- it sees XPath.pm, apparently. But I get another not found error: 
Can't load '\\otherbox\path\to\site\lib/auto/XML/Parser/Expat/Expat.dl
+l' for module XML::Parser::Expat: load_file:The specified module coul
+d not be found at C:\path\to/DynaLoader.pm line 229.
 at \\otherbox\path\to\site\lib/XML/Parser.pm line 14

[download]
I've changed the paths, but kept the varying slash directions. I've verified that Expat.dll exists at the location it's trying (if all the slashes are going the same way). Am I doing the 'use lib' part wrong for a network drive?

---
A fair fight is a sign of poor planning.

Replies are listed 'Best First'.
Re: Modules on network drives on Win32
by ikegami (Patriarch) on Mar 17, 2006 at 16:37 UTC
    Am I doing the 'use lib' part wrong for a network drive?

    I don't know, but it's easy to find out. Create a drive mapping for the directory, then try to load up the module through the drive mapping. If it works, it's pretty good sign UNC paths don't work.

    Alternatively, it could be a permission issue. This is being run as the web server.

[reply]

      If it finds XPath.pm, then I doubt it is being run from a web server. I thought that it might be a permissions problem specific to how the *.dll needs to be loaded, but I've done this same trick in order to allow people to use Tk-based Perl scripts that I've written when many people don't have Tk installed (everyone has Perl installed) 

      BEGIN {
    my $haveTk= eval { require Tk; 1 };
    if(  ! $haveTk  ) {
        my $perl= "//tye-desk/perl/bin/perl.exe";
        warn "Switching to Tye's copy of Perl since Tk isn't installed
+...\n";
        die "Can't access $perl: $! ($^E)\n"
            unless  -f $perl;
        system( 1, $perl, $0, @ARGV );
        exit( 0 );
    }
}

      [download]

      and that works even though my "perl" share is read-only. I doubt Perl's own loading of @INC based on the path to perl.exe is any better than "use lib" loading UNCs in the same way (and I just checked and @INC gets loaded with "//tye-desk/...").

      I'd probably debug DynaLoader (either just edit DynaLoader.pm or use "perl -d") so that it shows $^E which likely will give a better explanation of why it couldn't load the *.dll file.

      - tye        

[reply]
[d/l]
Re: Modules on network drives on Win32
by nimdokk (Vicar) on Mar 17, 2006 at 16:53 UTC
    Just a thought, you might want to load File::Spec up then use that to help set your path for 'use lib.'
[reply]

Back to Seekers of Perl Wisdom