The .profile is executed in a separate shell, which loads all the values, and then exits again, making all changes to the environment void. So you will need to employ something like tillys RE (tilly) 3: Get default login environment, which will import the environment set up by a shell script into the environment of the calling Perl process.

I downloaded the code you suggested but there appears to be an error in it! When I attempt to test it I get the following error -

syntax error at xxrcprofsub.pl line 8, near "m/^(.*?)=((?:[^\n\\]|\\.|
+\\\n)*)/gm
;"
[download]

Cheers, Ronnie

There's a closing ) missing on that line. Add it and the code will run... or see 408740.

Cheerio, Sören

00 00 * * * ksh -c '. /homes/myuser/.profile; /path/to/myscript.pl'
[download]

The root problem is that cron jobs run with a restricted environment.

The simplest solution is to edit interface's crontab, either setting SECTRAN_DIR = /home/interface/sectran at the top of the crontab file, or else in the command line which runs each script that needs it.

Actually it's not that cronjobs run in a restricted shell, the problem is that the OP is writing this settings to ~/.profile, which according to the docs:

When Bash is invoked as an interactive login shell, or as a non-interactive shell with the `--login' option, it first reads and executes commands from the file `/etc/profile', if that file exists. After reading that file, it looks for `~/.bash_profile', `~/.bash_login', and `~/.profile', in that order, and reads and executes commands from the first one that exists and is readable.

Pardon me for quoting the Bash docs, but this applies to any Bourne-type Shell.

Translated to english: the shell that runs a cronjob is not an interactive shell, therefor your profile is not being read. There might be no shell at all (depending on the cron implementation). This is way your carefully crafted PATH sometimes doesn't work when calling things from a cronjob. You can either do what brother Zaxo says, or you can write a shell script and put all your settings there (PATH, SECTRAN_DIR, PERL5LIB, whatever).

BTW, you can locally set an environment variable on the same command line when you run your script like this:



SECTRAN_DIR=/home/interface/sectran script.pl
[download]

$file = "/home/user/.profile";
grep(do{chop;s/(.*)=(.*)/$ENV{$1}=$2/e;},`. $file; env`);
[download]

I saw plenty of solutions, but nobody really explained the problem in the example to you. There are two key rules to environment variables in Unix-like systems:

1. Each process has its own environment, and each process can only modify its own environment.
2. When one process creates a child process, the environment of the parent process is copied into the new environment for the child.

Note that in addition to the sub-shell versus perl environment issue cited by many folks above, there is yet another barrier that keeps your original script from working the way you want:

Any statements within your script that modify %ENV will take effect at run-time. Meanwhile, perl will attempt to handle the "use sectran" directive at compile-time. Changes to %ENV within the script will come too late to have the intended effect, and this is another reason why insensate has the right approach, IMO.

update: Seeing elwarren's remark about using the BEGIN block to set %ENV, I believe that even this won't get the %ENV settings done soon enough to help with "use". At least, when I tried something like this:

BEGIN { $ENV{PERL5LIB} = "/some/special/lib" }
use SpecialModule;  # (a .pm file in /some/special/lib)
...
[download]