Perl - Local::lib not consistently finding the local path in @INC - conflict with perlbrew?

Question

I don't have root access to the system so I'm installing perl modules using local::lib which I installed using the bootstrapping method:

perl Makefile.PL --bootstrap=~/foo
make test && make install
echo '[ $SHLVL -eq 1 ] && eval "$(perl -I$HOME/perl5/lib/perl5 -Mlocal::lib)"' >>~/.bash_profile

I then successfully installed cpanm and used cpanm to install the module FAST. However when I try use the fasgrep function I get the following error:

% fasgrep
Can't locate FAST.pm in @INC (@INC contains: /usr/local/lib64/perl5 /usr/local/share/perl5 /usr/lib64/perl5/vendor_perl /usr/share/perl5/vendor_perl /usr/lib64/perl5 /usr/share/perl5) at /home/dpearton/perl5/bin/fasgrep line 5.

I've checked that FAST.pm is available in the local lib, it is but the system doesn't seem to be looking for it there.

according to the paths variables it should be looking in the right place:

$ echo PATH=$PATH ; env|sort|grep PERL
PERL5LIB=/home/dpearton/perl5/lib/perl5:/home/dpearton/perl5/lib/perl5
PERLBREW_BASHRC_VERSION=0.73
PERLBREW_HOME=/home/dpearton/.perlbrew
PERLBREW_ROOT=/home/dpearton/perl5/perlbrew
PERL_LOCAL_LIB_ROOT=/home/dpearton/perl5
PERL_MB_OPT=--install_base "/home/dpearton/perl5"
PERL_MM_OPT=INSTALL_BASE=/home/dpearton/perl5

I've even added export PER5LIB=$HOME/perl5/lib/perl5 to my .bash_profile and it still doesn't work.

I'm very new to using perl. Might the issue be that I've also got perlbrew installed? If so, how can I make a "clean" uninstall of prelbrew?

Answer 1

The shell in which you printed your environment shows PERL5LIB is set to add

/home/dpearton/perl5/lib/perl5

and

/home/dpearton/perl5/lib/perl5

to @INC, yet neither of those (identical) paths are found in @INC of the perl that tried to load FAST.pm.

Two possibilities:

• That perl inherited a different environment than the one you dumped, or
• That perl was started with -T (taint mode).

Check the shebang line of fasgrep to see if -T was used to rule out that possibility. I doubt that -T was used. It adds some safety checks to prevent user-input from ending up in executed commands. Removing -T would simply remove those checks. Since this script is neither externally accessible nor setuid, the benefits of -T are already quite minimal. If this is the issue, go ahead and remove it.

I suspect it's other possibility, especially since you showed fasgrep was started from a different prompt (%) than the one from which you ran set ($).