Whats the best way to call a routine every week?

[Yesideez]

Hi,

I'm trying to write a lottery program for a game and I've just got stuck.

I've got the players buying tickets ok but only problem is having the script know when it is. I'd like to have the script call a function every week at one or more specific dates (like Saturday at 7pm and/or Wednseday at 7pm) so a winning ticket can be chosen and the money handed out automatically.

Many thanks.

[Twey]

Errr... use cron? Don't reinvent the wheel.

[ddadmin]

Yep, cron job is the way to go: http://mkaz.com/ref/unix_cron.html

[Twey]

That's UNIX cron. Hosts nowadays are more likely to use vixie-cron. Here's my manpage (from vixie-cron-4.1-36.FC4):

CRON(8)                                                                CRON(8)

NAME
       cron - daemon to execute scheduled commands (ISC Cron V4.1)

SYNOPSIS
       cron [-l load_avg] [-n] [-p]

DESCRIPTION
       Cron should be started from /etc/rc or /etc/rc.local.  It will return immediately, so you don’t
       need to start it with ’&’.  The -n option changes this default behavior causing it  to  run  in
       the foreground.  This can be useful when starting it out of init.

       Cron  searches /var/spool/cron for crontab files which are named after accounts in /etc/passwd;
       crontabs found are loaded into memory.  Cron also searches for /etc/crontab and  the  files  in
       the  /etc/cron.d  directory, which are in a different format (see crontab(5)).  Cron then wakes
       up every minute, examining all stored crontabs, checking each command to see if  it  should  be
       run  in  the current minute.  When executing commands, any output is mailed to the owner of the
       crontab (or to the user named in the MAILTO  environment  variable  in  the  crontab,  if  such
       exists).

       Additionally,  cron  checks each minute to see if its spool directory’s modtime (or the modtime
       on /etc/crontab) has changed, and if it has, cron will then examine the modtime on all crontabs
       and  reload  those which have changed.  Thus cron need not be restarted whenever a crontab file
       is modified.  Note that the Crontab(1) command updates the modtime of the spool directory when-
       ever it changes a crontab.

   Daylight Saving Time and other time changes
       Local  time  changes of less than three hours, such as those caused by the start or end of Day-
       light Saving Time, are handled specially.  This only applies to jobs that  run  at  a  specific
       time  and  jobs that are run with a granularity greater than one hour.  Jobs that run more fre-
       quently are scheduled normally.

       If time has moved forward, those jobs that would have run in the interval that has been skipped
       will  be  run immediately.  Conversely, if time has moved backward, care is taken to avoid run-
       ning jobs twice.

       Time changes of more than 3 hours are considered to be corrections to the  clock  or  timezone,
       and the new time is used immediately.

   PAM Access Control
       On  Red Hat systems, crond now supports access control with PAM - see pam(8).  A PAM configura-
       tion file for crond is installed in /etc/pam.d/crond .  crond loads the  PAM  environment  from
       the pam_env module, but these can be overriden by settings in the crontab file.

SIGNALS
       On  receipt of a SIGHUP, the cron daemon will close and reopen its log file.  This is useful in
       scripts which rotate and age log files.  Naturally this is not relevant if cron  was  built  to
       use syslog(3).

CAVEATS
       In  this version of cron , without the -p option, /etc/crontab must not be writable by any user
       other than root, no crontab files may be links, or linked to by any other file, and no  crontab
       files may be executable, or be writable by any user other than their owner.

SEE ALSO
       crontab(1), crontab(5), pam(8)

AUTHOR
       Paul Vixie <vixie@isc.org>

And crontab:

NAME
       crontab - maintain crontab files for individual users (ISC Cron V4.1)

SYNOPSIS
       crontab [-u user] file
       crontab [-u user] [-l | -r | -e][-i]

DESCRIPTION
       Crontab  is the program used to install, deinstall or list the tables used to drive the cron(8)
       daemon in ISC Cron.  Each user can have their own crontab, and though these are files in  /var,
       they are not intended to be edited directly.

       If  the  cron.allow  file exists, then you must be listed therein in order to be allowed to use
       this command.  If the cron.allow file does not exist but the cron.deny file  does  exist,  then
       you must not be listed in the cron.deny file in order to use this command.  If neither of these
       files exists, only the super user will be allowed to use this command.

       If the -u option is given, it specifies the name of the user whose crontab is  to  be  tweaked.
       If  this  option is not given, crontab examines "your" crontab, i.e., the crontab of the person
       executing the command.  Note that su(8) can confuse crontab and that if you are running  inside
       of su(8) you should always use the -u option for safety’s sake.

       The  first  form of this command is used to install a new crontab from some named file or stan-
       dard input if the pseudo-filename ‘‘-’’ is given.

       The -l option causes the current crontab to be displayed on standard output.

       The -r option causes the current crontab to be removed.

       The -e option is used to edit the current crontab using the editor specified by the  VISUAL  or
       EDITOR  environment  variables.   After  you exit from the editor, the modified crontab will be
       installed automatically.

       The -i option modifies the -r option to prompt the user for a ’y/Y’  response  before  actually
       removing the crontab.

SEE ALSO
       crontab(5), cron(8)

FILES
       /etc/cron.allow
       /etc/cron.deny

STANDARDS
       The  crontab command conforms to IEEE Std1003.2-1992 (‘‘POSIX’’).  This new command syntax dif-
       fers from previous versions of Vixie Cron, as well as from the classic SVR3 syntax.

DIAGNOSTICS
       A fairly informative usage message appears if you run it with a bad command line.

AUTHOR
       Paul Vixie <vixie@isc.org>