view release on metacpan or  search on metacpan

docs/BaseLib-example1  view on Meta::CPAN

SH]   BEGIN {
SH]     for(split/:/,$ENV{PROJLIBDIR}) { use lib $_; }
SH]   }
SH] 
SH] your scripts can also refuse to run if PROJLIBDIR
SH] is not defined or looks suspicious.
SH] 
SH]   BEGIN {
SH]     for($ENV{PROJLIBDIR}){
SH]       croak "PROJLIBDIR is not defined!" unless defined;
SH]       ($_)=/(.*)/; # untaint like crazy
SH]       use lib $_;
SH]   }

Well, that's too much for the script. Besides, you missed
one bracket :-)

SH] and lastly, you can check to prevent the same
SH] directory included more than once if you want (as
SH] lib.pm doesn't do this currently).
SH] 

docs/BaseLib-example2  view on Meta::CPAN

[snipped]

SH] from the last two examples i can see why BaseLib might
SH] prove to be useful/convenient: it deals nicely with
SH] different versions of an application which a single user
SH] might run, where as it would be cumbersome to set
SH] different environment variables everytime one needs to
SH] switch versions. in addition it works with -T because it
SH] doesn't rely on the environment.

That's what I avoid. But there's still a tainted data, that's
the full path to script directory from FindBin. That's why
the data needs to be untainted first.


SH] so BaseLib-based scripts basically first uses FindBin to
SH] find itself, but then, instead of using relative path to
SH] connect to its LIBDIR, it looks for LIBDIR in its own
SH] path, because it must be there! (well, as long as LIBDIR
SH] is specified correctly). simple, but clever. now why
SH] hadn't the rest of us thought of that before? :-)

Yes, there must be some convention here. Both BASEDIR and