There's another characteristic problem that can affect programs run by cron
as compared with the command line (other than the interpretation of '%
' signs described by Robert Gamble).
That difference is in the environment. If the program run relies on special environment variables, then it will work when you run it from the command line, with the environment you normally use, and it will likely work if you run it with at
because that captures the environment when you create the job. But cron
does no special environment setting.
I habitually, therefore, configure cron
to run scripts by absolute pathname, and that script does the environment setting that I need (adds my $HOME/bin
directory to PATH, for example). I even have a standardized infrastructure for this - a shell script that sets the environment and runs other programs.
# @(#)$Id: crontab,v 4.2 2007/09/17 02:41:00 jleffler Exp $
# Crontab file for Home Directory for Jonathan Leffler (JL)
#-----------------------------------------------------------------------------
#Min Hour Day Month Weekday Command
#-----------------------------------------------------------------------------
0 * * * * /usr/bin/ksh /work1/jleffler/bin/Cron/hourly
1 1 * * * /usr/bin/ksh /work1/jleffler/bin/Cron/daily
23 1 * * 1-5 /usr/bin/ksh /work1/jleffler/bin/Cron/weekday
2 3 * * 0 /usr/bin/ksh /work1/jleffler/bin/Cron/weekly
21 3 1 * * /usr/bin/ksh /work1/jleffler/bin/Cron/monthly
The script in /work1/jleffler/bin/Cron
sets the environment and then runs the script of the same name in /work1/jleffler/bin
to do the real work. The names in the Cron
sub-directory are actually all links to the same script.