Re: use lib in cgi env

[kcott]

G'day perlig,

Your main problem seems to be that the directory structures of your test and production environments do not mirror each other. The relative path for your test environment would be:

use lib './modules';

but, for your production environment, you'd need

use lib '../modules';

While you may need different settings (such as in a configuration file), you shouldn't be changing code between development and testing environments nor between testing and production environments. If you do make code changes, then you're neither testing what you developed not delivering what was tested.

Furthermore, the scenario you describe suggests that you are going to have to make code changes in the production environment. This is something you should strenuously avoid if you wish to maintain a stable production environment.

I would expect you to encounter related problems for the life of the application while your environments remain out of sync.

I don't have enough information to provide a definitive answer on how to fix this. Here's a few potential options (that allow use lib './modules'; to work everywhere):

• Move /home/user/webpage/trunk/index.pl to /home/user/webpage/index.pl
• Move /home/user/webpage/modules/ to /home/user/webpage/trunk/modules/
• Create a symlink called /home/user/webpage/trunk/modules/ which points to /home/user/webpage/modules/

However you decide to fix this, make sure it applies to all environments: I mentioned development in addition to test and production - you may have others.

[space_monk]

The development environment looks as though its an SVN (Subversion) checkout, hence the inclusion of the trunk in the path. If so, the originator does get top marks for version controlling his code. Having said that, he should probably have just checked out a copy of the trunk to a local sandbox and avoided having "trunk" in the path.

svn co http://your_repository/trunk local_directory is a good way to avoid this. This would have solved the discrepancy between his "development" and "production" relative paths and avoided the problem described. I still stick to my earlier statement that setting PERL5LIB or similar environment variable is the best way to resolve the problem. I presume the production version runs as a different user from the development version, so this could be accomplished by setting the environment variable in ~/.bashrc or the Apache config files.

I'll leave exactly how to do that as a Google exercise as its getting past my bedtime :-)

[AlexTape]

itīs a little bit complicated.. but the "productive env" is in that case a "productive test env" ;-) whatever.. i mind of these things you say.. thank you!