All the Perl that's Practical to Extract and Report

Getting people to stop using FindBin

Aristotle on 2007-08-05T07:48:15

Granted, the correct alternative to FindBin is quite cumbersome. If it’s as annoying as this, and FindBin largely “works”, people will just shrug and do the wrong thing because it’s easier and its brokenness doesn’t usually affect them – an understandable reaction.

So I’m thinking I should wrap up the right approach in a tarball and put it on CPAN; something like lib::relative where in the simplest case you can just say use lib::relative.

But it could also do more; consider the following:

# preconditions:
# Cwd::cwd() eq '/home/jrh'
# $0 eq 'bin/foo.pl`

use File::Spec::Functions qw( catpath splitpath rel2abs catdir );
use lib catpath( ( splitpath( rel2abs $0 ) )[ 0, 1 ], catdir( qw( lib perl5 ) ) );

# postconditions:
# $INC[0] eq '/home/jrh/bin/lib/perl5'

It would be trivial to have lib::relative’s import take extra arguments that are interpreted as path segments, so the above doozy becomes just this:

use lib::relative qw( lib perl5 );

Is FindBin unfixable?

jhi on 2007-08-05T12:40:23

If FindBin were fixable, it could be spun off the core and CPANized (and if you work fast, Rafael might squeeze it in for 5.10.0...)

Re:Is FindBin unfixable?

Aristotle on 2007-08-05T13:22:45

It seems quite unfixable to me. The whole point of FindBin is that if it can’t locate the script via $0 it will try to find it in the PATH – and that is also the source of its brokenness, because it leads to bizarre failure modes every once in a blue moon, when FindBin finds something and thinks it’s the script, when it’s not.

Ripping that behaviour out 10 years after the fact doesn’t seem wise, even if the behaviour is broken for some edge cases. I’d prefer to deprecate FindBin in favour of a saner new alternative.