Environemnt under cron execution

[Brian Bientz]

How is the environment determined when a job executes under CRON? Obviously, the .profile is not being loaded. When my job executes under CRON, the only thing in the PATH variable is /usr/bin and /usr/sbin. Should I manually source the .profile for the user in my script? Or, is there a more elegant solution to setting the environment?

[Patrick Wallek · Accepted solution]

The best bet is to set your environment for your script within the script. You should always use absolute paths for commands (/usr/bin/ls, etc.) and any other environment variables should be set within the script itself.

You could source the .profile for the user, but since .profile expects an interactive session you will get some errors like "stty: not a typewriter".

[Martin Johnson]

as part of your cron entry:

* * * * * . ./.profile > /dev/null; your_cron_script

HTH
Marty

[A. Clay Stephenson]

The cron environment is intentionally very sparse. You almost certainly do not want to source a .profile in your script.

Your script can explicitly set PATH and export it or a better method is to do something like this:

Let's suppose that this is some kind of Oracle script so the ORACLE_HOME, ORACLE_SID .. needs to be set.

The best way is to create a file. e.g. /usr/local/bin/oraenv.sh that sets and exports these variables and the PATH; this file must not have a return or exit statement.
Now BOTH the .profile AND your cron script source source /usr/local/bin/oraenv.sh.

The reason you don't source .profile is that several statements (e.g. stty, tabs, ...) require a tty device for stdin & stdout.

You could wrap those commands in your .profile with
if [ -t 0 -a -t 1 ]
then
tset ..
stty ..
tabs ..
fi

but it's much cleaner to have a common file that is references by all the relevant .profiles and scripts.

Regards, Clay

[Shannon Petry]

Like Clay pointed out, cron and at environments are very sparse for security reasons. When I write scripts, I sourse files like Clay suggested depending on whether it is an admin user, normal user, superuser. Once these are setup, it is very clean and can handle all your needs.

Something I really like in Linux is /etc/system/functions. While some of it would not make sense in other Unices the basic functions for super-user needs are there.
i.e.
killproc()
statproc()

I took the idea back in Redhat 5.0 and ran with it. I now have some extensive external functions and paths (based on OS) which make scripting a breeze.

Best of Luck!
Shannon

[Frank Slootweg]

Adding to the other responses:

This subject matter, i.e. environment variables and non-execution of .profile, is documented in the crontab(1) (i.e. "man crontab") manual page. It is documented in this page, and not in the cron(1M) page, because crontab(1) is a user command (i.e. the user which puts the entry in the crontab) and cron(1M) is a SysAdmin command.