Beefy Boxes and Bandwidth Generously Provided by pair Networks
laziness, impatience, and hubris

FindBin is broken (RE: How do I get the full path to the script executing?)

by tye (Sage)
on Nov 13, 2000 at 00:10 UTC ( #41213=note: print w/replies, xml ) Need Help??

in reply to Re: How do I get the full path to the script executing?
in thread How do I get the full path to the script executing?

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 )
as another answer mentions.

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? (:

        - tye (but my friends call me "Tye")

Replies are listed 'Best First'.
Re: FindBin is broken
by Aristotle (Chancellor) on May 28, 2002 at 18:46 UTC
    This reply is very late, but I think needs adding. rel2abs($0) will probably break if you are running setuid on a modern Unix. To avoid a race condition, these kernels do not pass the filename of a setuid script to its interpreter but rather a "virtual" filename (somewhere in /proc on Linux if I'm not mistaken) which is rigidly associated to the file the kernel opened. The filename Perl sees in that case and consequently the $0 value would bear no relation to the actual location of the script. (Of course, FindBin will not work any better in that case.)

    Makeshifts last the longest.

Re: FindBin is broken (RE: How do I get the full path to the script executing?)
by merlyn (Sage) on Jan 17, 2001 at 02:57 UTC
    Ahh. Suppose you call chdir before you call FindBin. I believe it will still work. But your rel2abs($0) will no longer be accurate.

    So, with the caveat that you cannot call chdir before rel2abs, you can use it in place of FindBin.

    -- Randal L. Schwartz, Perl hacker

      I tried to come up with a situation like you described where would work but rel2abs($0) wouldn't.

      The only case I found was pretty strange and, IMHO, just shows more ways in which is broken. If you happen to be chdir()ed into a directory that is in your $ENV{PATH} and do "perl subdir/script" and subdir/script does a BEGIN { chdir "/tmp" } before you can do your rel2abs($0), then rel2abs($0) will be wrong (returning "/tmp/subdir/script").

      But will see the "/" and assume that $ENV{PATH} doesn't need to be searched (which makes sense), but then will find that "./subdir/script" doesn't exist and so will change its mind. Then it will search $ENV{PATH} and will stop at the first path that actually contains a "subdir/script" in it. If that place also happens to be the directory that you happened to be in before the super-early chdir(), then will have found, by accident, the correct path to the script.

      Personally I'd rather have never search $ENV{PATH} and have it die "You chdir()ed too early" if ! -e $0 so that such strangeness could be detected rather than returning whatever it finds which might be right or might be wrong. That test isn't completely foolproof, but the ways to fool it are even more bizarre.

              - tye (but my friends call me "Tye")
        And that is why I wrote scriptname. :-)
        []s, HTH, Massa (κς,πμ,πλ)
Re: FindBin is broken (RE: How do I get the full path to the script executing?)
by zrajm (Beadle) on Feb 17, 2009 at 19:18 UTC
    Looking around for a solution to the above problem I found:
    use Cwd 'abs_path'; my $scriptpath = abs_path($0);
    ..but then of course I explicitly wanted to follow any symlinks, so that I could place script & data in the same separate directory, put a symlink to the script in my $PATH, and have the script dig figure out where to read its data by following that link.

    See also:

Re: FindBin is broken (RE: How do I get the full path to the script executing?)
by ruoso (Curate) on Jan 13, 2012 at 17:39 UTC
Re: FindBin is broken (RE: How do I get the full path to the script executing?)
by choroba (Cardinal) on May 21, 2012 at 10:24 UTC
    Has the perversion gone away with the new version 1.51 of FindBin? In perldelta for 5.16.0, it says:
    It no longer returns a wrong result if a script of the same name as the current one exists in the path and is executable.
        You can't install FindBin from cpan, you can only upgrade perl ... so FindBin is fixed in the latest perls ... its still broken in all the old ones

Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://41213]
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others drinking their drinks and smoking their pipes about the Monastery: (6)
As of 2023-10-04 10:16 GMT
Find Nodes?
    Voting Booth?

    No recent polls found