Well, I've complained about this particular module before because I think the perverse way in which it was implemented is quite unfortunate because it makes it nearly impossible to use it for lots of useful things like finding other programs that might be on your PATH. (After all, it is called FindBin and $0 is a script, not a binary.)

But when this question came up in chatterbox, I did some checking and it appears to me that the correct answer for the full path to the current script is simply:

    rel2abs( $0 )
[download]

For those that don't know, the (perverse) FindBin module goes through some effort to search $ENV{PATH} trying to find your script. However, I can't come up with any situation in which the script would have been found on the $ENV{PATH} but that $0 would not contain the (full) path, so the module appears to be pretty useless.

Now, the closely related problem of finding the full path to the current executable of, for example, a C program, is solved (as best as is possible) via a method very similar to what the FindBin module does. However, this isn't the same problem.

Now, a C program's value of argv[0] can be whatever the invoking program wanted to pass to exec(), including something completely unrelated to the name of the executable file. For the common case where argv[0] is set to the base name of the executable, searching $ENV{PATH} makes sense. For other cases, it may be impossible to determine the path to the executable. But, for a Perl script, the value of $0 is set by Perl and Perl doesn't set it to strange values (so we don't have these cases where we can't determine the full path) and often sets it to the full path for you.

Okay, I can think of two cases where $ENV{PATH} is searched in order to find a Perl script. First, the kernel (or any other program such as a shell or a web server) might search the path to find "script" and then, reading the "#!/usr/bin/perl" line of "script", it would then invoke "perl", telling it to read the script.

So, the kernel (or other program) will run "perl", passing the name of the script to be executed. Will it expect "perl" to search the $ENV{PATH} in order to find the script? No. So it will pass the full path to the script (or a path relative to the current working directory if there is one and the program feels like doing that work -- which some of them do). "perl" will just set $0 to whatever it was given so we'll either get 1) the full path to the script or 2) a path relative to the current directory. We don't need to search $ENV{PATH}.

Second, you can do "perl -S script" to tell "perl" to search $ENV{PATH}. What does $0 get set to in this case? Well, my testing on multiple platforms shows $0 gets set to the full path.

So throw in the third case of the user doing "perl script" or "perl subdir/script" and you see that $0 is always set to either 1) the full path or 2) a path relative to the current directory. So FindBin can give you the wrong answer and goes to lots of work (in a perverse way) in order to do it.

Did I mention that I think FindBin is perverse? (: