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 ]