You think you need to use sudo. You don't. You're not trying to empty root's Trash folder. You have permission to delete files in your own ~/.Trash folder, so you don't need to become root (which is what sudo does) to do the rm.
You can simply use:
* * * * * rm -rf ~/.Trash/*
Note, I'd also advise against using ~ in a dangerous command like this (any time you're calling rm -rf it's potentially dangerous). Put the full path to the .Trash folder so it's very explicit what will happen when the line is executed. Something like /Users/yourusername/.Trash/. So:
* * * * * rm -rf /Users/yourusername/.Trash/*
Where you replace yourusername with your actual user name on the host.
When cron runs an event, it uses the default shell environment of the running UID. However, no "profile" customization is applied, i.e. your .bash_profile is not sourced and thus any PATH settings are not picked up. As well, I don't believe that the common profiles are picked up either. As such, you probably have no PATH or LD_LIBRARY_PATH environment settings available to the process you're trying to launch and this is why pdfimages and gs isn't being picked up by default.
In the past, I've solved this one of two ways:
- Directly reference the full path of the file I need.
- Create a wrapper shell script for the job.
I typically prefer the 2nd one since it not only allows me to set up an environment for the job to run in, but it also makes it relatively easy to add debug situations easily. For example, if the job isn't working right I can just edit the shell script and put in STDOUT redirection to a debug file.
So in short, I would have a cron entry of
* 6 * * * cd /path/to/ && ./executable.sh
.. which would change to the path, but the executable.sh would do all the export PATH, export LD_LIBRARY_PATH, etc. to get my job set up.
Your sample executable.sh could be as simple as this:
#!/bin/bash
# if you want to just pick up your profile, you can '.' source it
. ~/.bash_profile
export PATH=/where/i/find/gs
export LD_LIBRARY_PATH=/if/i/need/libs
(./executable 2&>1) >executable.out
The executable.out file redirection isn't necessary since without it all STDOUT goes to cron.out, but it does make it a bit cleaner to do it this way. Also the 2>&1 nonsense with the parenthesis makes sure that both STDERR and STDOUT make it into the output file; this helps with debugging why a job didn't run.
Best Answer
Figured it out.
You have to escape the % in cron, so should read like this: