23 05 * * * /Users/your_name/bin/perl-script and arguments
[download]

crontab cron.txt
[download]

For more details check the following man pages from your command shell:

man cron
man crontab
man 5 crontab # This explains the layout of the cron file
[download]

Thanks for the quick response.

I'm having a bit of trouble and I think it's just related to my ignorance of UNIX. I created the text file, cron.txt as you suggested. I then did the whole "crontab cron.txt" thing. My question is, after the first 5 variables are declared (Minute, Hour, etc.), what is the "sixth" variable exactly? I thought it was the command that I would execute if I was at the command prompt. So, for me, I put in something like perl -w ~/path/to/script.pl.

I guess I should put the whole thing

23 13 * * * perl -w ~/path/to/script.pl

But, it doesn't seem to execute. What to do?

Hi, I don't know much about OS X, but some OS have additional security restrictions. E.g., your UID might need to be listed in /etc/cron.allow and not in /etc/cron.deny (ALL matches every user) to be eligible to execute cronjobs.

Usually cronjobs are executed under plain /bin/sh, so you might explicitly want to change that. Furthermore, I would not trust tilde expansion. It might work, but using $HOME/path/to/script.pl or even manually expanding ~/ might help here. Most cron systems allow to set SHELL and HOME in the cronjob file.

Perl should be in your $PATH, but expanding that to /usr/bin/perl - or wherever perl is installed on your system is more reliable and secure. If your script.pl accesses some non-standard environment variables (i.e., via %ENV) you might need to explicitly start your standard shell (see: /etc/passwd) or use a wrapper.

So, you might end up with: 23 13 * * * /usr/bin/perl -w /home/prince9/path/to/script.pl
where /home/prince9 is the output of echo ~ and /usr/bin/perl is hopefully the output of type perl ... have a look at e.g. /var/log/messages too...

Cron jobs tend to run in a less "rich" environment, so you do need to be more explicit about things like paths. In particular, cron on (BSD-based) macosx uses "sh" instead of "bash", which means that the tilde is treated as just a tilde, not a special abbreviation for $HOME. However, cron will start you out in your home directory, so instead of tilde, you can just use period. Also, your PATH will be limited to "trusted" directories (not including ".") If your perl script begins with the standard shebang line:

#!/usr/bin/perl
[download]

and if the current "mode flags" on the script file allow it to be executable (use the chmod +x to make the script executable), then your crontab entry can simply be:

23 13 * * * /absolute/path/to/script.pl
[download]

(plus any args that the script might need for its @ARGV). Note that if the script writes anything to STDOUT or STDERR, this material will be sent to your mac login account as an email message (check out the unix "mail" command), unless your cron entry includes redirection on the command line, e.g.:

23 13 * * * ./mypath/to/script.pl > cron.out 2> cron.err
[download]

In that example, "./" represents your home directory, which is where the output files will be created.

If it is, that would be the way I recommend.

Cron does exist, but launchd is the "preferred" mechanism.

Automator's probably barking up the wrong tree; that's more of a point-and-drool interface for setting up AppleScript-able events (not that AppleScript wasn't an attempted "ANYONE R PROGRAMR" interface; if that's what you're after though consider Mac::Glue instead).

The cake is a lie.
The cake is a lie.
The cake is a lie.

Since you're not a formal programmer tilly's advice above might be better but you don't need an intermediate file stage to work with the cron tools. The -e flag starts an editor on the current, or a scratch, crontab. I edit mine on OS X (every version since the public beta has had cron) this way-

And to see what your crontab currently looks like-

To see what editor will be used try-

moo@cow[1]~>env | grep EDITOR
EDITOR=emacs
[download]

Proably shouldn't mess with it if you're not familiar with whatever name pops up.

I avoid -e for the simple reason that I really like having my crontab documented in a file that is under source control.

Indeed. You may have converted me just by saying it. I started putting my own utility scripts and such for various sites, checks, updates into revision control only recently. I've long done it for lib files but a month or two ago started getting all the incidentals I take for granted, like crontabs, in there too. Never again will a trashed hard drive cost me more than the money to replace it and the time to restore it.

Looks like the editor is vi, which I know nothing about. It's been a billion years since I've worked in a UNIX environment -- time to dust off some old books I guess.

The 'at' command has the added advantage over cron that it is not tied to a specific instant of time. If you schedule a job to run in 'cron' to run at 1pm every day, and the system happens to be down at 1pm, the job will not run until 1pm the next day. With 'at', if you schedule the job to run at 1pm, and the system is down until 2pm, then when it comes up at 2pm, the job will run then.

Of course, you have to add extra logic to have it re-schedule itself if it is a periodic job.

Not only is cron your friend in the Unix world, there is also the at command.

For completeness, it has to be said that at used to rely on an atrun command scheduled to run under cron every ten minutes, IIRC: in modern implementations it is based on an atd daemon itself instead, and atrun is a convenient script left there for compatibility.

More interestingly, it has to be said that PC's as commonly used tend not to be turned on 24/7, and thus cron (or whatever) scheduling should be tailored on the user's habits. Alternatively, I know there to exist an anacron utility, which:

is a computer program that performs periodic command scheduling which is traditionally done by cron, but without assuming that the system is running continuously. Thus, it can be used to control the execution of daily, weekly, and monthly jobs (or anything with a period of n days), on systems that don't run 24 hours a day. Anacron was originally conceived and implemented by Christian Schwarz in Perl, for the Unix operating system. The current implementation, in C, was written by Itai Tzur and is actively maintained by Sean 'Shaleh' Perry.

Unfortunately, AIUI it is not much known nor used, especially by major Linux distros, which often schedule "housekeeping" operations at times at which the computer will likely be off, instead. Incidentally and in the same vein as above, anacron is not a daemon but must be scheduled with cron - a design which I personally find entirely reasonable.

(Sorry for replying so late!)

--
If you can't understand the incipit, then please check the IPB Campaign.

I use cron for this kind of thing. I have never used iCal events to run programs, but some people apparently do it that way.