Re: Re: (jeffa) Re: Problems with using strict

A couple of ways...

Put the module in the directory where the script runs
Add use lib '/path/to/my/modules' before using any of your modules
Update: Set the environment variable PERLLIB or PERL5LIB to the location of your modules

90% of every Perl application is already written. ⇒

dragonchild

Comment on Re: Re: (jeffa) Re: Problems with using strict Download Code

Replies are listed 'Best First'.
Re: Re: Re: (jeffa) Re: Problems with using strict by halley (Prior) on Apr 20, 2003 at 13:01 UTC
These are indeed three ways to adjust where modules are found. Some extra notes: Don't expect '.' to be in @INC if it may be run by `root`; perl reigns in that behavior for uid==0. I really don't care much for `use lib '/hard/wired/path'` especially in a multiple-platfom corporate deployment environment. There is no '\\winsvr\perl\extensions\lib' on Solaris and no '/corp/home/perl' on Windows, for example. I made a corporate-specific setup module which (among many other things) performed the equivalent @INC adjustment but only after doing a few heuristic checks to decide the appropriate path. Then any corporate-specific script could just 'use DynaCorp;' to reap the benefits. Let the system administrators `setenv PERLLIB` to appropriate site-wide values. Don't adjust or assume the value of PERLLIB on behalf of a single script or application, it really complicates installation of that script into new environments. Imagine trying to tell a co-worker that this tool will help them, but neither you nor they have permissions to adjust PERLLIB without a hackish wrapper BAT file or .sh script. -- `[ e d @ h a l l e y . c c ]`	[reply]

Replies are listed 'Best First'.

These are indeed three ways to adjust where modules are found. Some extra notes:

Don't expect '.' to be in @INC if it may be run by root; perl reigns in that behavior for uid==0.
I really don't care much for use lib '/hard/wired/path' especially in a multiple-platfom corporate deployment environment. There is no '\\winsvr\perl\extensions\lib' on Solaris and no '/corp/home/perl' on Windows, for example. I made a corporate-specific setup module which (among many other things) performed the equivalent @INC adjustment but only after doing a few heuristic checks to decide the appropriate path. Then any corporate-specific script could just 'use DynaCorp;' to reap the benefits.
Let the system administrators setenv PERLLIB to appropriate site-wide values. Don't adjust or assume the value of PERLLIB on behalf of a single script or application, it really complicates installation of that script into new environments. Imagine trying to tell a co-worker that this tool will help them, but neither you nor they have permissions to adjust PERLLIB without a hackish wrapper BAT file or .sh script.

--
[ e d @ h a l l e y . c c ]