It should be easy.
Agreed, and I know issues like this can be frustrating to debug, so I hope some clarification is helpful:
the @INC is correctly updated ... That fails because cpan didn't update @INC environment correctly. ... the user environment @INC is updated by cpan
Sorry, no, because it's not cpan's job to change @INC or the environment. cpan just installs modules into the directories that are available.
installing modules as root to avoid the issue for a user is also a work-around, and not a good one
Well, if you're installing modules into the system Perl, then normally only root has access to those directories.
Here's a brief and slightly simplified overview of what's going on here:
The solution is to fix the root cause.
I hope you see now that the root cause here is the environment provided by cron.
This being Perl, there are a bunch of different solutions: a bunch of different ways to set PERL5LIB so that it's available even when scripts are run by cron (one example), other ways to set up @INC so that it always includes the directory where the modules are installed, and ways of installing modules so that perl can always find them (as I've described). So many, in fact, that I don't think listing them all here will be very helpful - each has its advantages and disadvantages, also depending on things like whether you need the modules to be available to all users or even all scripts that you want to run, and so on. So I'll just make a few suggestions of solutions (not workarounds!), and if you need more information, feel free to ask and provide more details of how you want your setup to look.
You can keep using local::lib, and as I've said before you can set up PERL5LIB in your crontab, since this really is the root cause. It's pretty simple: From your shell where things work, run echo $PERL5LIB, then take that value and stick a new line PERL5LIB=... at the top of your crontab (like PERL5LIB=/home/darren/perl5/lib/perl5).
Using perlbrew, you can install your own version(s) of Perl into your home directory (by default under ~/perl5/perlbrew). When you install Perl into a single directory like this, the nice thing is that it does not spread its library paths (the ones compiled into the perl binary) all around the system - instead they are all contained underneath that one directory, no fiddling around with PERL5LIB or local::lib necessary!
So for example, I just used perlbrew to install Perl v5.26.2 on one of my Raspberry Pis. I disabled the local::lib environment variables, and now can do perlbrew use perl-5.26.2, and then use cpan to install modules into that Perl normally. And, I can now run that copy of Perl from my crontab via /home/pi/perl5/perlbrew/perls/perl-5.26.2/bin/perl, with access to all the modules!
Although as I said, installing modules into the system Perl has risks, if it's only one module and this is just a single-user system (in my experience on a Raspberry Pi one just tends to stick with the default pi user), the risk isn't too great. Since you've already got local::lib set up for the normal user, it might be easiest to not try and clean that up, and instead log in as root via sudo -i and then just run cpan from there. The advantage of this method over the above two is that the modules become available to everyone.
In reply to Re^7: Perl app won't compile /run from cron
by haukex
in thread Perl app won't compile /run from cron
by dazz
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |