<SCHEDULE [options] WHEN=schedule [--] [var=val] [...]>
SCHEDULE directive causes the script to be periodically
executed, according to the given
WHEN schedule. The
WHEN schedule is a string with one of the following syntaxes:
] WEEK[S|LY] [ON]weekday timeofday
] MONTH[S|LY] [ON] [THE] FIRST|SECOND|THIRD|FOURTH|n
|DAY [OF THE MONTH]timeofday
with these additional definitions:
] MIN[UTE[S]] [[REPEAT] n
SCHEDULE may also be called as a function; it returns 0 on error,
1 if ok, and 2 if nothing done (scheduler disable via
The primary function usage is to unschedule a script (with
set to "
off") or all scripts ("
In addition to the
WHEN schedule, the following options may appear
SCHEDULE directive or function:
START=dateThe starting date for the schedule, as a Texis-parseable date/time. This defaults to
now. The first run of the schedule will be the next valid
WHENevent on or after
START. It is recommended that a
STARTdate be given if the
WHENargument is of the
] MINUTESsyntax, if the script is to start at a fixed wall-clock time (e.g. every hour, but on the hour).
URLEND=/func.txtSpecifies the function and MIME-type file extension (here) to be appended to the script name when run. This allows a function other than
<main>to be the starting point for the script run.
COMMENT=textSpecifies a short text comment to be associated with this schedule. This is viewable when the
-LScommand-line option is used (here), and can be use to denote the purpose of each scheduled event.
SCRIPT=fileScript to schedule/unschedule. Only valid if called as function; directive script is always current script. Default is main script (non-module).
Set space-separated list of flags. May include:
Run jobs mutually-exclusive: do not start a scheduled run of the script if a previous run of the same script same schedule is still active. Scripts should still run their own mutex check however, as this only prevents scheduled collisions, not web or command-line runs from colliding.
Do not mutually-exclude runs. Default in version 7 and earlier.
FLAGS was added in version 7.02.1409016000 20140825. Note
that previous versions will take this option as a variable assignment.
Indicates end of options, and that all arguments that follow (if any) are variable assignments to pass to the script. Ensures that any var assignments will not be confused with options. Added in version 7.02.1409016000 20140825.
After all options, a list of variable assignments may be given. These will be passed to the script when it is run, allowing user-defined configuration options to be set.
<SCHEDULE> tags are permitted, e.g. to run different
parts of the script at different times. To unschedule a script, remove
<SCHEDULE> tag and re-compile or re-run the script, use
-sched all-off, or
For more information on scheduling, see the Scheduling section, here.
<SCHEDULE WHEN="daily at 10pm">
<SCHEDULE WHEN="every month on the first Sunday at 4am"
The first example schedules the script to run the
function every day at 10pm local time. The second example runs
<monthly> function on the first Sunday of every month, at 4am.
<SCHEDULE> tag was added in version 3.01.985400000
20010323. The function syntax was added in version 3.01.988150000
The script must be compiled, either explicitly via the
or implicitly by running the source, for the
to take effect, since Vortex must be made aware of it.
The Texis Monitor (
monitor) is responsible for starting
scheduled scripts, so it must be running for
SCHEDULE to work.
vhttpd will start the
Texis Monitor; alternatively it may be automatically run by the OS at
machine boot (under Windows the install program for Texis arranges
this). Make sure it is run as the Texis user, not