ikegami:

I think he meant it as a way to avoid something like:

$ mkdir -p TEST/{bin,sl}/lib

$ echo -e "package myLib;\nour \$VERSION=1.1;\n" >TEST/sl/lib/myLib.pm

$ echo -e "package myLib;\nour \$VERSION=1.7;\n" >TEST/bin/lib/myLib.p
+m

$ cp printval.pl TEST/bin

$ cd TEST/bin

$ ./printval.pl 
myLib version: 1.7
search path: /home/marco/TEST/bin/lib
/etc/perl
/usr/local/lib/perl/5.10.1
    . . .

$ cd ../sl

$ ln --symbolic ../bin/printval.pl printval

$ ./printval 
myLib version: 1.1
search path: /home/marco/TEST/sl/lib
/etc/perl
/usr/local/lib/perl/5.10.1
    . . .

$ cat ../bin/printval.pl 
#!/usr/bin/perl
use strict;
use warnings;
use File::Basename;
use Cwd 'abs_path';
my $f;
BEGIN {
    unshift(@INC, abs_path(dirname($0).'/lib'));
}
use myLib;
print "myLib version: ", $myLib::VERSION, "\n";
print "search path: ", join("\n", @INC[0 .. 2], "\t. . ."), "\n";
[download]

...roboticus

When your only tool is a hammer, all problems look like your thumb.

I hope not because switching from $0 to __FILE__ would not help resolve that problem at all. $0 eq __FILE__ in both runs.

In case you missed it, I brought up that problem and posted a solution to it earlier in the thread: swap the order of abs_path and dirname.

He's surely referring to adding to @INC in a file that's loaded using require or do.

ikegami,

From what I remember, it was an issue for me only twice in the past.

• 1) When running a system wide test harness on independent subsystem test scripts.
• 2) While executing scripts using require or do like you stated above

Anyway, both were very obscure cases that haven't come up again, and both could be worked around using alternative methods of course. Nevertheless, I still use the __FILE__ out of habit now.

ikegami:

Gah! You're right. I should've spent the extra minute to try it with __FILE__ instead of $0. Oh, well, it can serve as yet another example of "test, don't assume!"

...roboticus

When your only tool is a hammer, all problems look like your thumb.