A few of the many uses for scheduled commands are:
~~ Email WillMaster Possibilities ezine at 12:08 GMT every Tuesday.

~~ Do automatic database updates at night when the server is less busy.

~~ Send a robot to select sites for verifying certain links are present.

~~ Send a weekly report to you about how much server space you're using.

Almost anything that needs to be done according to a schedule and that doesn't need direct human supervision can be set up with Unix/Linux CRON.

Note: Some hosting companies don't give their accounts telnet or SSH (a secure telnet-like connection) access to the server. A few, in lieu of such access, provide a control panel to set up CRON schedules. Others do not provide CRON scheduling at all.

To create a CRON schedule, put a list of commands and their schedules in a plain text file. This text file is called the "CRON table." Upload the CRON table to your server. Then telnet or SSH to your server.

Once at your server, type CRONtab filename  replacing "filename" with the file name of the CRON table you uploaded to your server. This will register your CRON table with the CRON system.

If you want to verify that the CRON system has indeed registered your CRON table, type:

CRONtab -l

(the letter el, not the number 1). That will display a list of the current registered CRON schedules.

The CRON table has six fields. The first five fields are schedule time fields and the sixth is the command itself:

1. The minute of the hour the command shall execute.

2. The hour the command shall execute.

3. The day of the month the command shall execute.

4. The month the command shall execute.

5. The day of the week the command shall execute.

6. The command.

All six fields are on one line. There is one space between each field. Only field 6 may contain spaces within itself. Here is an example of what a schedule might look like:

10 3 1 1 * /usr/bin/perl /www/cgi-bin/script.cgi

Comments in the CRON table, ignored by the server, are lines beginning with the # symbol.

The order of the fields might seem backward. Most of us are used to thinking hour before minute, as in 9:45. Also month before day, as in June 21. However, the fields are minute before the hour and day before month, with the day of the week as the fifth field.

Here are the first five fields and their allowed values:

Allowed

Field Values

----- -------

Minute 0-59

Hour 0-23

Day of the Month 1-31

Month 1-12 (also 3-letter month abbr)

Day of the Week 0-7 (also 3-letter day of week abbr)

Each of the above values can also contain ranges, lists, and step values. If a field contains an asterisk (*), it tells CRON to accept all allowed values.

Example

-------

Range 1-3

List 3,5,7

Step 15-45/5 (another example: */5)

For explanation, let's assume the above is in the Minute field.

Range 1-3 is a range of 1 through 3, inclusive, and means 1, 2, or 3 minutes after the hour.

List 3,5,7,9 means 3, 5, 7, or 9 minutes after the hour. Step 15-45/5 means every 5 minutes while the clock is 15 through 45 minutes after the hour, inclusive.

Step */5 means every five minutes while the clock is 0 through 59 minutes after the hour (* meaning all allowed values, which would be range 0-59 minutes).

For purposes of explaining each field, let's use three hypothetical situations.

1. A script must run one minute before the end of every year.

2. A script must run at 2:20 every Tuesday morning.

3. A script must run every 15 minutes from 9 in the morning to 9 in the evening. And it must run every 30 minutes the rest of the time. (Note, this requires two schedule lines.)

The minute is the first field. The values examples of range, list, and step, above, illuminate the versatility built into the system.

For each of the three hypothetical situations, the minute field would be:

1. 59

2. 20

3a. */15

3b. */30

The hour is the second field. The allowed values are the same as the minute field, 0-59.

For each of the three hypothetical situations, the hour field would be:

1. 23

2. 2

3a. 9-21

3b. 0-8,22-23

The day of the month is the third field. The allowed values are 1 through 31.

For each of the three hypothetical situations, the day of month field would be:

1. 31

2. *

3a. *

3b. *

The month is the fourth field. The allowed values are 1 through 12. Instead of digits, 3-letter abbreviations may be used:

1 2 3 4 5 6 7 8 9 10 11 12

jan feb mar apr may jun jul aug sep oct nov dec

For each of the three hypothetical situations, the month field would be:

1. 12

2. *

3a. *

3b. *

The day of the week is the fifth field. The allowed values are 0 through 7. Digits 1 through 6 represent Monday through Saturday, respectively. On some systems, 0 represents Sunday and on others 7 represents Sunday. On a few systems, both 0 and 7 represent Sunday. Your hosting company can tell you which applies to your server. Or, you may wish to try 0 and see if the script runs on Sunday. If it doesn't, try 7. Instead of digits, 3-letter abbreviations may be used:

0 1 2 3 4 5 6 7

sun mon tue wed thu fri sat sun

For each of the three hypothetical situations, the day of week field would be:

1. *

2. 2

3a. *

3b. *

For each of the three hypothetical situations, the complete schedule (with an example sixth field) would be:

1. 59 23 31 12 * /usr/bin/perl /www/cgi-bin/script.cgi

2. 20 2 * * 2 /usr/bin/perl /www/cgi-bin/script.cgi

3a. */15 9-21 * * * /usr/bin/perl /www/cgi-bin/script.cgi

3b. */30 0-8,22-23 * * * /usr/bin/perl /www/cgi-bin/script.cgi

The sixth field is the actual command that will be executed according to the schedule specified in the first five fields. The sixth field includes any parameters to be passed to the command.

When the command is a Perl script, you might or might not need to specify the location of Perl as part of the command. Your hosting company can tell you which applies for your server.

Here are a three command examples:

/www/cgi-bin/script.cgi

/usr/bin/perl /www/cgi-bin/script.cgi

/usr/bin/perl /www/cgi-bin/script.cgi response.txt

The first example is a Perl script without the location of Perl being specified.

The second example is the same script, but this time the location of Perl is specified.

The third example includes a parameter. Here, the parameter is "response.txt," which might be the file name that an autoresponder is to send, assuming the autoresponder script is named script.cgi. When a script requires parameters, it's instructions should clearly indicate what the parameters are and what they represent.

On-line Documentation for CRON and CRONtab

You can type either or both of the following commands at the telnet or SSH prompt for the on-line CRON and CRONtab manuals. (It is assumed that any hosting company with CRON available also has the manuals on-line.)

man CRON

man CRONtab

Those two on-line manuals provide a lot of technical information.

You can use the following script to practice what you have learned.

#!/usr/bin/perl
# Verify above line is correct for your server.

use strict;

my @date = localtime;

$date[4]++;

$date[5] += 1900;

$date[5] = substr($date[5],2);

open W,">track.txt";

print W "$date[2]\:$date[1]\:$date[0] on ";

print W "$date[4]\/$date[3]\/$date[5]\n";

# Above is USA style date. For European
# style, reverse digits 4 and 3. close W;
# end of practice script

The script will create a file named "track.txt" and print the time and date. Every time it runs, it creates a new file. The script is specifically made for running from the telnet/SSH prompt or with CRON, not for a browser. (Running this script in your browser will generate an internal server error. That's because the script never returns anything to the browser.)

When the script is uploaded, you can test it from the telnet/SSH prompt. To test, type the command you'll be using when you create the CRON schedule.

Once the script runs correctly, create the CRON schedule. You may wish to use */3 or something similar in the minute field while testing. As you now know, that will launch the script every three minutes; then the longest you'll wait between tests is three minutes.

Once the test is over, remove the test script from the CRON schedule. Launching a script, whether with CRON or through a browser, does take some server resources.

Using CRON, you can schedule events from simple to sophisticated timing. It's all specified in the first five fields.