In this case, it may not work. It all depends on who's crontab the script is executed from and what that user's home directory is. For instance, if it is in the Apache user's crontab and their home is /var/www, then that's where the script would be executed, and would not know how to find the 'lib' dir from there, as it would first have to locate 'cgi-bin'.

One can test where cron scripts are being run out of by using the following code snip:

#!/usr/bin/perl
use warnings;
use strict;

use Cwd;
print getcwd();
[download]

Then, set up a crontab to call the script and output the result to a file (this entry is for root):

$ sudo crontab -e

* * * * * /home/steve/cron.pl > /home/steve/cron.out
[download]

That prints "/root" to the 'cron.out' file.

Set up a crontab for my personal user that does the same thing, and cron.out will contain '/home/steve'. If the OP puts something like this into the crontab of the user calling the real script, it'll identify the issue immediately.

There are always two common problems when trying to run a script from cron. The first is that cron does not have environment variables set (unless you do so explicitly in the crontab), so it has no knowledge of PATH. This means that you must specify a full path to the script cron is trying to call. The other common issue is what we're seeing in the OP's post (from what I can tell), where cron can execute the script, but the location it is being run out of is not what is expected.

Using full paths is the easiest way to get cron-run scripts to do the right thing. If one does need to use a relative path, it must be relative to the home directory of the user who's crontab is running the script.