Loading Perl Modules from same directory as script

[Donald Gillies]

Well, after only 6 hours of hacking around trying to do something that
should be obvious in perl - but isn't - i seem to have found two
solutions :

PROBLEM : Your team is developing a tree of perl scripts. Any
developer can check out a private and executable copy of the tree.
You want each developer to reference their own private checked-out
library modules without hacking on the checkout code or hack on the
developer's environment variables, etc.

For the sake of simplicity, you want the library modules and the perl
scripts to live in the same directory when they are checked out. I am
using Perl v5.8.0.

SOLUTION #1 : "PORTABLE SOLUTION"

BEGIN {
$my_exe = `which $0`;
while (substr($my_exe, length($my_exe) - 1, 1) ne "/") { chop($my_exe); }
push @INC,$my_exe;
}
require MyModule;

SOLUTION #2 "IF ITS MORE THAN ONE LINE IN PERL THEN ITS PROBABLY WRONG"

BEGIN { # load libraries from THIS SCRIPT'S directory
push @INC, `csh -c "set a=\\\`which $0\\\` ; echo -n \\\${a:h}"`;
}
require "getSlots.pm";

========================================

Now that I have two solutions, is there a third and "Right" way to
solve this problem ?? I cannot believe that PERL module search paths
are relative to directory where you run the command vs. relative to
the directory where the executable files live - this makes no sense at
all, maybe its job security for taintperl to exist or for some other
pointless and nonsensical reason ...

- Don Gillies
San Diego, CA

[Donald Gillies]

After only 6 hours of hacking around trying to do something that
should be obvious in perl - but isn't - i seem to have found two
solutions :

PROBLEM : Your team is developing a tree that has a directory
containing perl scripts. Any developer can check out a private and
executable copy of the tree. You want the scripts run by each
developer to reference their own private checked-out library modules,
and for the sake of simplicity, you want the library modules and the
perl scripts to live in the same directory when they are checked out.
I am using Perl v5.8.0.

SOLUTION #1 : "ALMOST PORTABLE SOLUTION" - in every script you put ...

BEGIN {
$my_exe = `which $0`;
while (substr($my_exe, length($my_exe) - 1, 1) ne "/") {
chop($my_exe); }
push @INC,$my_exe;
}
require "MyModule.pm";

SOLUTION #2 "IF ITS MORE THAN ONE LINE IN PERL THEN ITS PROBABLY
WRONG"

BEGIN { # load libraries from THIS SCRIPT'S directory
push @INC, `csh -c "set a=\\\`which $0\\\` ; echo -n \\\${a:h}"`;
}
require "MyModule.pm";

========================================

Now that I have two half-working solutions, is there a "Right" way to
solve this problem ?? I cannot believe that PERL module search paths
are relative to directory where you run the command vs. relative to
the directory where the executable is found - this makes no sense at
all, maybe its job security for taintperl to exist or for another
pointless and nonsensical reason ...

- Don Gillies
San Diego, CA

[A. Sinan Unur]

[email]gillies@cs.ubc.ca[/email] (Donald Gillies) wrote in news:dsr1jf$k1b$1
@cascade.cs.ubc.ca:

> After only 6 hours of hacking around trying to do something that
> should be obvious in perl - but isn't - i seem to have found two
> solutions :
>
> PROBLEM : Your team is developing a tree that has a directory
> containing perl scripts. Any developer can check out a private and
> executable copy of the tree. You want the scripts run by each
> developer to reference their own private checked-out library modules,
> and for the sake of simplicity, you want the library modules and the
> perl scripts to live in the same directory when they are checked out.

....

> Now that I have two half-working solutions, is there a "Right" way to
> solve this problem ?? I cannot believe that PERL module search paths
> are relative to directory where you run the command vs. relative to
> the directory where the executable is found - this makes no sense at
> all, maybe its job security for taintperl to exist or for another
> pointless and nonsensical reason ...

Huh?

perldoc FindBin

perldoc lib

Sinan

--
A. Sinan Unur <1usa@llenroc.ude.invalid>
(reverse each component and remove .invalid for email address)

comp.lang.perl.misc guidelines on the WWW:
[url]http://mail.augustmail.com/~tadmc/clpmisc/clpmisc_guidelines.html[/url]

[harryfmudd [AT] comcast [DOT] net]

Donald Gillies wrote:

> Well, after only 6 hours of hacking around trying to do something that
> should be obvious in perl - but isn't - i seem to have found two
> solutions :
>
> PROBLEM : Your team is developing a tree of perl scripts. Any
> developer can check out a private and executable copy of the tree.
> You want each developer to reference their own private checked-out
> library modules without hacking on the checkout code or hack on the
> developer's environment variables, etc.
>
> For the sake of simplicity, you want the library modules and the perl
> scripts to live in the same directory when they are checked out. I am
> using Perl v5.8.0.
>
> SOLUTION #1 : "PORTABLE SOLUTION"
>
> BEGIN {
> $my_exe = `which $0`;
> while (substr($my_exe, length($my_exe) - 1, 1) ne "/") { chop($my_exe); }
> push @INC,$my_exe;
> }
> require MyModule;
>
> SOLUTION #2 "IF ITS MORE THAN ONE LINE IN PERL THEN ITS PROBABLY WRONG"
>
> BEGIN { # load libraries from THIS SCRIPT'S directory
> push @INC, `csh -c "set a=\\\`which $0\\\` ; echo -n \\\${a:h}"`;
> }
> require "getSlots.pm";
>
> ========================================

Solution #3 : Portable, and pure perl.

use File::Basename;
use lib basename ($0);

This is cold-coded, but should work. I know I have done 'use lib' with a
computed argument before.

Tom Wyant

[Paul Lalli]

Donald Gillies wrote:

> After only 6 hours of hacking around trying to do something that
> should be obvious in perl - but isn't - i seem to have found two
> solutions :

Actually, it's painfully obvious to anyone who bothers to check the
built-in Perl FAQ before starting a 6-hour "hacking" mission.

> PROBLEM : Your team is developing a tree that has a directory
> containing perl scripts. Any developer can check out a private and
> executable copy of the tree. You want the scripts run by each
> developer to reference their own private checked-out library modules,
> and for the sake of simplicity, you want the library modules and the
> perl scripts to live in the same directory when they are checked out.

> Now that I have two half-working solutions, is there a "Right" way to
> solve this problem ??

Generally, one looks for the "RIGHT" solution *before* wasting six
hours to create a wrong solution.

> I cannot believe that PERL module search paths
> are relative to directory where you run the command vs. relative to
> the directory where the executable is found - this makes no sense at
> all,

I think it makes perfect sense, actually. Why should I, by default,
care where the program is actually living if I just want to include a
module in my current directory?

> maybe its job security for taintperl to exist or for another
> pointless and nonsensical reason ...

Ahhh, there's the mark of a good developer - when you don't understand
something, whine, bitch, moan, and insult.

For future reference to anyone reading this thread - the OP would have
saved himself six hours by a simple check of the Perl FAQ:

perldoc -q directory
. . .
How do I add the directory my program lives in to
the module/library search path?

use FindBin;
use lib "$FindBin::Bin";
use your_own_modules;


Boy, that was hard, wasn't it?

Paul Lalli

[Donald Gillies]

"Paul Lalli" <mritty@gmail.com> writes:

>Donald Gillies wrote:

>> After only 6 hours of hacking around trying to do something that
>> should be obvious in perl - but isn't - i seem to have found two
>> solutions :

>Actually, it's painfully obvious to anyone who bothers to check the
>built-in Perl FAQ before starting a 6-hour "hacking" mission.

I recommend you might want to add "soc.manners" to your list of
newgroup subscriptions.

Why do you even bother to answer questions in this newsgroup ?? You
certainly are NO HELP to someone looking for answers.

True, I have only been programming professionally for 30 years, and
programming PERL intermittantly for 10 years, so you cannot expect me
to know everything. But, I spent my first of 6 hours looking in
google and on [url]www.perl.com[/url] for an answer, and when none was
forthcoming, i wrote two solutions. Then, I spent another half hour
looking for a better solution - in google groups - and reading 2
separate PERL FAQS - before posting my question.

- Don Gillies
San Diego, CA

[Paul Lalli]

Donald Gillies wrote:

> "Paul Lalli" <mritty@gmail.com> writes:
>

> >Donald Gillies wrote:

> >> After only 6 hours of hacking around trying to do something that
> >> should be obvious in perl - but isn't - i seem to have found two
> >> solutions :

>

> >Actually, it's painfully obvious to anyone who bothers to check the
> >built-in Perl FAQ before starting a 6-hour "hacking" mission.

>
> I recommend you might want to add "soc.manners" to your list of
> newgroup subscriptions.

Really? Would that group teach me the manners necessary to write such
condescending and insulting tripe as:

> > > I cannot believe that PERL module search paths
> > > are relative to directory where you run the command vs. relative to
> > > the directory where the executable is found - this makes no sense at
> > > all, maybe its job security for taintperl to exist or for another
> > > pointless and nonsensical reason ...

?

> Why do you even bother to answer questions in this newsgroup ?? You
> certainly are NO HELP to someone looking for answers.

I can't see how you could possibly be the judge of that, as you were
not looking for answers, and I was not attempting to give them. You
had already found your own solutions, and had been told by two others
the "Right" solutions. I was pointing out how you wasted your own time
by not bothering to check the FAQ, and how you decided your own
inability to find the correct solution must imply a deficiency in the
language and those who wrote it.

> True, I have only been programming professionally for 30 years, and
> programming PERL intermittantly for 10 years,

And yet you never learned the proper name of the language? See:
perldoc -q difference

> so you cannot expect me to know everything.

I expect no one to know everything. I do expect people to check the
FAQ before embarking on a 6-hour coding mission to see if something has
already been done, and certainly before insulting the authors of the
language in a world-wide newsgroup.

> But, I spent my first of 6 hours looking in google

Yes, because random web searches are always better than the official
built-in documentation...

> and on [url]www.perl.com[/url] for an answer, and when none was
> forthcoming, i wrote two solutions. Then, I spent another half hour
> looking for a better solution - in google groups - and reading 2
> separate PERL FAQS - before posting my question.

So you chose either to ignore the official Perl FAQ, or to not actually
read it but pretend to?

Paul Lalli

[Jim Gibson]

In article <dstbn9$rs8$1@cascade.cs.ubc.ca>, Donald Gillies
<gillies@cs.ubc.ca> wrote:

> "Paul Lalli" <mritty@gmail.com> writes:
>

> >Donald Gillies wrote:

> >> After only 6 hours of hacking around trying to do something that
> >> should be obvious in perl - but isn't - i seem to have found two
> >> solutions :

>

> >Actually, it's painfully obvious to anyone who bothers to check the
> >built-in Perl FAQ before starting a 6-hour "hacking" mission.

>
> I recommend you might want to add "soc.manners" to your list of
> newgroup subscriptions.
>
> Why do you even bother to answer questions in this newsgroup ?? You
> certainly are NO HELP to someone looking for answers.

Actually, Paul is one of the most helpful people posting in this
newsgroup. He did provide you with an answer, didn't he?

>
> True, I have only been programming professionally for 30 years, and
> programming PERL intermittantly for 10 years, so you cannot expect me
> to know everything. But, I spent my first of 6 hours looking in
> google and on [url]www.perl.com[/url] for an answer, and when none was
> forthcoming, i wrote two solutions. Then, I spent another half hour
> looking for a better solution - in google groups - and reading 2
> separate PERL FAQS - before posting my question.

Your initiative and perseverance in trying to find your own solution
are to be commended. I think that it is your poor attitude that might
put people off. You seem to have blamed Perl for your difficulty in
finding the "Right" answer. After programming Perl for 10 years, you
should know that Perl's module search paths are in the @INC array and
neither relative to the directory where the command is run nor to the
directory where the executable is found. Lose the attitude and you will
find many more helpful people on this newsgroup.

Posted Via Usenet.com Premium Usenet Newsgroup Services
----------------------------------------------------------
** SPEED ** RETENTION ** COMPLETION ** ANONYMITY **
----------------------------------------------------------
[url]http://www.usenet.com[/url]

[Phil Harvey]

I had the exact same problem, but I wanted to find a portable solution which introduced no additional dependencies and was backward compatible to Perl 5.004. This is my solution:


my $exeDir;
BEGIN {
# get exe directory
$exeDir = ($0 =~ /(.*)[\\\/]/) ? $1 : '.';
# add lib directory at start of include path
unshift @INC, "$exeDir/lib";
}
# ... "use" modules normally after this ...

[Unregistered]

Had the same problem, perl sucks, move to python.

[Unregistered]

Other than not being portable, is anything wrong with this method?

BEGIN { require './MyPackage.pm'; }
my $pkg = new MyPackage;

..seems to work in Perl 5.10.