in reply to Modules on network drives on Win32

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.

Replies are listed 'Best First'.
Re^2: Modules on network drives on Win32 (works for me)
by tye (Sage) on Mar 17, 2006 at 21:22 UTC

    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 ); } }

    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