Clear questions and runnable code
get the best and fastest answer
Inconsistent failure to find moduleby davies (Parson)
|on Feb 16, 2012 at 18:02 UTC||Need Help??|
davies has asked for the
wisdom of the Perl Monks concerning the following question:
I am writing a module using TDD, and the tests are all passing. The module refers to another module, PodProc.pm, that is currently in a different directory. I point to it with the command use lib 'Z:/Data/Perl/PodExt';. Code from PodProc.pm is tested. However, I want this combination to interact with BugZilla. I am therefore writing a cgi module that, so far, manipulates the BugZilla database as I want. However, adding a use statement to the cgi module results in an error message Can't locate PodProc.pm in @INC (@INC contains: Z:/Data/Perl/PodExt F:/BugZilla F:/Perl/site/lib F:/Perl/lib).
This appears in the Apache error log while the browser shows a 500 Internal Server Error. I have checked that the capitalisation is identical (but the tests pass even if it's different) and originally used backslashes instead of slashes. The tests pass either way and I get the error from Apache either way. Checking the directory from the command prompt shows PodProc.pm in Z:\Data\Perl\PodExt - if it didn't, I would expect the tests to fail.
Searching indicates that use lib and changing @INC may behave differently, but since @INC is reported as containing the relevant directory, I haven't tried any other approach.
What should I try next, please?
Update: Thank you all. Yes, it was Apache, not Perl, that was the problem (no wonder I couldn't fix it - I was looking in the wrong place). While there was nothing in the Windows configuration preventing Apache seeing the network, Apache's httpd.conf had rules prohibiting it from accessing almost anything.
However, I report for future users that simply changing the rules wasn't enough. Because Apache loads itself at system boot time, before the user has logged into the network, putting the path, however well qualified, into the config file didn't cut the mustard. I'm sure there is a way, but the only way I could restart Apache completely was to restart the system.
My solution, which seems to be working fine, was to put a short cut to the network directory into one of the directories to which Apache already had access and to put this path into the config file as though it were not a short cut. Since the browser can't be launched until the user has logged on, the cgi file won't run until everything is in place. Apache can't spot the network linkage because it doesn't run the code and so doesn't complain.