There are three common causes for cron job commands to behave differently compared to commands typed directly into an interactive shell, in rough order of commonness:
- Cron provides a limited environment, e.g., a minimal
$PATH, and other expected variables missing.
- Cron invokes
/bin/sh by default, whereas you may be using some other shell interactively.
- Cron treats the
% character specially (it is turned into a newline in the command).
- Cron doesn't provide a terminal or graphical environment.
You must precede all
% characters with a
\ in a crontab file, which tells cron to just put a percent in the command. Remember that when you use the
date command in a cron job.
55 8 * * 3 /usr/bin/php /home/mark/dev/processes/customClient/events.php > "/home/mark/dev/processes/customClient/events-$(date +\%Y-\%m-\%d --date='last Wednesday')-$(date +\%Y-\%m-\%d).csv"
0 9 * * 3 /usr/bin/echo 'The csv for last week, trying my hand at automatiging this' | /usr/bin/mutt <emailaddress> -s "Events from $(date +\%Y-\%m-\%d --date='last Wednesday')-$(date +\%Y-\%m-\%d)" -a "/home/mark/dev/processes/customClient/events-$(date +\%Y-\%m-\%d --date='last Wednesday')-$(date +\%Y-\%m-\%d).csv"
I also fixed some quoting problems:
- This wasn't causing you problems other than with legibility, but you shouldn't use backticks for command substitution. Use
$(…) instead: its parsing rules are simpler.
- Always use double quotes around variable and command substitutions:
"$(somecommand)". Here the lack of quotes was harmless because the
date command never returned any special character for the formats you used, but you have to carefully remember which characters are special and check this every time you leave a substitution unquoted. Keep it simple, always use double quotes unless you want field splitting and filename generation to happen on the result.
- You had some single quotes preventing expansion around some command substitutions. Use double quotes instead.