RE (tilly) 3: Get default login environment -- Classic code snippet.

Cheers, Sören

I have had a similar problem a few weeks ago, and it is probably not a Perl problem. I had a shell script connecting to an Oracle database, retrieving some data and then only launching a Perl program to do things with the data. When run from the shell prompt, everything went fine, but it did not work when launched as a cron job. The problem had to do with environment variables necessary to access the Oracle database, which were set properly when working in interactive mode from the ksh or bash prompt, but not set when launched under the cron tab. You probably have to find which environment variables are missing and set them somehow in your script.

Hard to fully diagnose without also seeing the actual cron. If you use a fully qualified path from the cron to mkvdts2ac3, when calling it, and use an absolute path to mkvmerge, when calling it from mkvdts2ac3. There should really be no problems.

OTOH are these shell scripts, or Perl scripts? Makes a big difference. Given this is a Perl related web site. I'll have to assume they're Perl scripts. In which case, divulging their code, or at least the relevant portions may better shed some light. That way, allowing someone here an opportunity to provide informative advice.

In any case, you'll probably need to effectively export a minimal $PATH to the script(s). In order to squelch the error.

Best wishes.

--Chris

#!/usr/bin/perl -Tw
use Perl::Always or die;
my $perl_version = (5.12.5);
print $perl_version;

As mentioned in my original question, I have written a perl script that does a number of things (in perl), however, some of the things it does is calls out to some third-party shell scripts (mkvdts2ac3) which also calls another third-party script (mvkmerge) to do various things. When calling these other scripts is where the path seems to get lost if calling through cron. I've tried specifying in cron, in the scripts themselves, but since these are third party scripts, I was hoping to not to have to modify them directly. It sounds like that's probably my only option at this point.

I just wanted to see how other have gotten around similar situations.

Thanks

This is not an uncommon issue. The solution I use is to set the environment prior to calling the script I want ot run

30 01 * * * * . /path/to/myenv.env; /path/to/myscript
[download]

So setting $PATH is only the beginning

You can read more about this in Re^3: DBD::mysql fail install check (crontab debugging troubleshooting DYLD_LIBRARY_PATH ldd otool ...)