So... it must be the case that /usr/bin/perl on the machine where this cron job is running happens to be 5.8.8, because your script has /usr/bin/perl on the shebang line, and that is what cron must be running.
Are you doing your interactive shell testing on a different machine? Or is your interactive shell environment set up such that /usr/bin/perl is somehow superseded in your PATH by a 5.10 installation? (and/or you have PERL5LIB initialized in some way that doesn't carry over into cron jobs)
Anyway, if it's true that perl 5.10 exists somewhere on the machine where cron is running, and that the module in question has been installed for that instance of perl 5.10, and you actually want to use 5.10, and you can find the path to that instance (e.g. do type perl in your shell), then just put that path as the shebang line in the script.
Update: actually, I'm not sure I'm convinced by the diagnostics you've shown so far. Did you really try a cron job that just did "/usr/bin/perl -V" ? If not, do that first. Then, if it really is 5.8.8, just change the shebang line to get 5.10 instead.
If /usr/bin/perl is already 5.10, now it's a question of making sure you know where the module is, or maybe just making sure it gets installed in the "normal" way (with root permission, under /usr). If it's in some path not covered by the default @INC, and you want to use that, just add something like this to your script:
use lib '/offbeat/path/for/misc_modules';
| [reply] [Watch: Dir/Any] [d/l] [select] |
I dont have type perl but which perl produced /usr/local/bin/perl which checks out ok. I added it to the shebang and the /etc/crontab PATH variable. Looks like its running ok now. Thanks for all the help.
| [reply] [Watch: Dir/Any] [d/l] [select] |
| [reply] [Watch: Dir/Any] [d/l] |