mirror of
https://salsa.debian.org/dskoll/remind.git
synced 2026-04-16 06:18:47 +02:00
7557 lines
275 KiB
Groff
7557 lines
275 KiB
Groff
.TH REMIND 1 "@RELEASE_DATE@" "Remind" "VERSION @VERSION@"
|
||
.SH NAME
|
||
remind \- a sophisticated reminder service
|
||
.SH SYNOPSIS
|
||
.B remind [\fIoptions\fR] \fIfilename\fR [\fIdate\fR] [\fI*rep\fR] [\fItime\fR]
|
||
.SH DESCRIPTION
|
||
\fBRemind\fR reads the supplied \fIfilename\fR and executes the commands
|
||
found in it. The commands are used to issue reminders and alarms. Each
|
||
reminder or alarm can consist of a message sent to standard output, or
|
||
a program to be executed.
|
||
.PP
|
||
If \fIfilename\fR is specified as a single dash '-', then \fBRemind\fR
|
||
takes its input from standard input. In this case, if \fBRemind\fR
|
||
has been compiled against the GNU Readline library, it will use
|
||
Readline to give you an interactive line-editing interface.
|
||
.PP
|
||
If \fIfilename\fR happens to be a directory rather than a plain file,
|
||
then \fBRemind\fR reads all of the files (but not any subdirectories!)
|
||
in that directory that match the pattern "*.rem". The files are read
|
||
in sorted order; the sort order may depend on your locale, but should
|
||
match the sort order used by the shell to expand "*.rem".
|
||
|
||
.PP
|
||
\fBRemind\fR reads its files starting from the beginning to the end, or
|
||
until it encounters a line whose sole content is "__EOF__" (without the quotes.)
|
||
Anything after the __EOF__ marker is completely ignored.
|
||
|
||
.SH MODES OF OPERATION
|
||
\fBRemind\fR has four major modes of operation:
|
||
.TP
|
||
.B Agenda Mode
|
||
Agenda mode is the default mode. In this mode, \fBRemind\fR prints
|
||
today's reminders on standard output and exits. It may fork a background
|
||
process to pop up queued reminders for later in the day.
|
||
.TP
|
||
.B Calendar Mode
|
||
In this mode, \fBRemind\fR generates a calendar either by drawing it
|
||
in the terminal or by sending data in computer-readable format to a back-end
|
||
program that actually draws the calendar.
|
||
.TP
|
||
.B Daemon Mode
|
||
This is a special mode of operation in which \fBRemind\fR is invoked
|
||
by a front-end and runs as a daemon, accepting requests from
|
||
the front-end and sending messages back to the front-end.
|
||
\fBTkRemind\fR uses \fBRemind\fR in daemon mode.
|
||
.TP
|
||
.B Purge Mode
|
||
In this mode, \fBRemind\fR produces no output, but creates new versions of
|
||
its input files with all expired reminders commented out.
|
||
|
||
.SH OPTIONS
|
||
\fBRemind\fR has a slew of options. If you're new to the program,
|
||
ignore them for now and skip to the section "REMINDER FILES".
|
||
.TP
|
||
.B \-n
|
||
The \fB\-n\fR option causes \fBRemind\fR to print the \fBnext\fR occurrence
|
||
of each reminder in a simple calendar format. You can sort this by
|
||
date by piping the output through \fBsort(1)\fR. Note that the \fB\-n\fR
|
||
option causes any \fB\-g\fR option to be \fIignored\fR and also implicitly
|
||
enables the \fB\-o\fR option.
|
||
.TP
|
||
.B \-j\fR[\fIn\fR]
|
||
Runs \fBRemind\fR in "purge" mode to get rid of expired reminders.
|
||
See the section PURGE MODE for details.
|
||
.TP
|
||
.B \-r
|
||
The \fB\-r\fR option disables \fBRUN\fR directives and the \fBshell()\fR
|
||
function.
|
||
.TP
|
||
.B \-c\fI[flags]\fIn\fR
|
||
The \fB\-c\fR option causes \fBRemind\fR to produce a calendar that is
|
||
sent to standard output. If you supply a number \fIn\fR, then a
|
||
calendar will be generated for \fIn\fR months, starting with the
|
||
current month. By default, a calendar for only the current month is
|
||
produced. This option implicitly enables the \fB\-o\fR option.
|
||
.RS
|
||
.PP
|
||
You can precede \fIn\fR (if any) with a set of flags. The flags
|
||
are as follows:
|
||
.TP
|
||
.B '+'
|
||
causes a calendar for \fIn\fR
|
||
weeks to be produced.
|
||
.TP
|
||
.B 'a'
|
||
causes \fBRemind\fR to display reminders on the calendar on the
|
||
day they actually occur \fIas well as\fR on any preceding days
|
||
specified by the reminder's \fIdelta\fR. This \fIalso\fR causes
|
||
\fBRemind\fR to include text outside %"...%" sequences that would
|
||
otherwise be removed (though the actual %" markers themselves are removed.) \"" Add comment to avoid Emacs highlighting problems
|
||
.TP
|
||
.B 'l'
|
||
causes \fBRemind\fR to use VT100 line-drawing characters to draw
|
||
the calendar. The characters are hard-coded and will only work
|
||
on terminals that emulate the VT00 line-drawing character set.
|
||
.TP
|
||
.B 'u'
|
||
is similar to 'l', but causes \fBRemind\fR to use UNICODE line-drawing
|
||
characters to draw the calendar. The characters are hard-coded and will
|
||
only work on terminals that are set to UTF-8 character encoding. This
|
||
flag also enables the use of the UNICODE "left-to-right" mark that
|
||
can fix up formatting problems with right-to-left languages in the calendar
|
||
display.
|
||
.TP
|
||
.B 'z'
|
||
has the effect of setting the system variable \fB$TerminalHyperlinks\fR
|
||
to 1. See the documentation of this variable in the section "SYSTEM VARIABLES"
|
||
.TP
|
||
.B 'c'
|
||
causes \fBRemind\fR to use VT100 escape sequences to approximate
|
||
SPECIAL COLOR reminders. Note that this flag is kept for
|
||
backwards-compatibility; you should use the \fB\-@\fI[n][,m][,b]\fR
|
||
command-line option instead.
|
||
.PP
|
||
In a UTF-8 locale, \fBRemind\fR will use "left-to-right marks" when
|
||
creating a calendar with the \fB\-c\fR option. Some terminals don't
|
||
handle this correctly and garble the rendering of the calendar; see
|
||
the documentation of \fB$SuppressLRM\fR in the section "SYSTEM
|
||
VARIABLES" for a workaround.
|
||
.RE
|
||
.TP
|
||
.B \-@\fR[\fIn\fR][,\fIm\fR][,\fIb\fR]
|
||
Tells \fBRemind\fR to approximate SPECIAL COLOR and SHADE reminders
|
||
using VT100 escape sequences. The approximation is (of necessity)
|
||
very coarse, because the VT100 only has eight different color
|
||
sequences, each with one of two brightnesses. A color component
|
||
greater than 64 is considered "on", and if any of the three color
|
||
components is greater than 128, the color is considered "bright".
|
||
.RS
|
||
.PP
|
||
If you supply the optional numeric parameters, the have the following
|
||
meanings: \fIn\fR=0 tells \fBRemind\fR to use the standard 16 VT100
|
||
colors. \fIn\fR=1 tells it to use an extended 256-color palette supported
|
||
by many terminal emulators such as xterm. And \fIn\fR=2 tells it to
|
||
use escape sequences that support true 24-bit colors, again supported
|
||
by many terminal emulators such as xterm.
|
||
.PP
|
||
If the optional \fIm\fR parameter is supplied following a comma, then
|
||
\fIm\fR=0 tells \fBRemind\fR that the terminal background is dark, and
|
||
\fBRemind\fR will brighten up dark colors to make them visible. If
|
||
\fIm\fR=1, then \fBRemind\fR assumes the terminal background is light
|
||
and it will darken bright colors to make them visible. If \fIm\fR is
|
||
specified as 2, then \fBRemind\fR does not perform any adjustments,
|
||
and some reminders may be hard or impossible to see if the color is
|
||
too close to the terminal background color. If you supply the letter
|
||
\fBt\fR rather than a number, then \fBRemind\fR attempts to guess the background
|
||
color of the terminal, \fIeven if\fR stdout is not a terminal.
|
||
.PP
|
||
On startup, if the standard output is a terminal, \fBRemind\fR
|
||
attempts to determine if the terminal background is dark or light by
|
||
sending a special escape sequence to determine the background color.
|
||
The \fIm\fR parameter can override this check (or force it if
|
||
\fIm\fR is given as \fBt\fR.)
|
||
.PP
|
||
If the optional \fIb\fR parameter is supplied following a comma, then
|
||
\fIb=0\fR tells \fBRemind\fR to ignore SPECIAL SHADE reminders (the
|
||
default) and \fIb=1\fR tells \fBRemind\fR to respect SPECIAL SHADE
|
||
reminders by emitting VT100 escape codes to color the background of the
|
||
calendar cell. Note that SHADE does not work well unless you are
|
||
using the extended 256-color palette (\fIn\fR=1) or the true
|
||
24-bit colors (\fIn\fR=2). Note that for calendar cells that are
|
||
shaded, the clamping mechanism described earlier for \fIm=0\fR or
|
||
\fIm=1\fR is skipped; it is assumed that if you set \fIboth\fR the
|
||
foreground color of a reminder and the background color of a cell,
|
||
then you know what you are doing.
|
||
.RE
|
||
.TP
|
||
.B \-w\fR\fIcol\fR[,\fIpad\fR[,\fIspc\fR[,\fIspc2\fR]]]]
|
||
The \fB\-w\fR option specifies the output width, padding and spacing
|
||
of the formatted calendar output. \fICol\fR specifies the number of
|
||
columns in the output device. If \fIcol\fR is not specified, or is
|
||
specified as 0, it defaults to the larger of 71 or the actual width of
|
||
your terminal, or to 80 if standard output is not a terminal. If
|
||
\fIcol\fR is specified as the letter \fBt\fR, then \fBRemind\fR
|
||
attempts to get the width of the \fB/dev/tty\fR terminal device. This
|
||
is useful, for example, if you pipe calendar output into \fBless\fR;
|
||
even though standard output is a pipe, you want the calendar to be
|
||
sized correctly for your terminal window:
|
||
.RS
|
||
.PP
|
||
.nf
|
||
remind -c -wt .reminders | less
|
||
.fi
|
||
.RE
|
||
|
||
.RS
|
||
.PP
|
||
Note that the value of \fIcol\fR is also used to set the system variable
|
||
$FormWidth, which is initialized to \fIcol\fR - 8. See "SYSTEM VARIABLES"
|
||
for details.
|
||
|
||
.PP
|
||
\fIPad\fR specifies how many lines
|
||
to use to "pad" empty calendar boxes. This defaults to 5. If you
|
||
have many reminders on certain days that make your calendar too large
|
||
to fit on a page, you can try reducing \fIpad\fR to make the empty
|
||
boxes smaller. \fISpc\fR specifies how many blank lines to leave
|
||
between the day number and the first reminder entry. It defaults to
|
||
1. \fIspc2\fR may be 0 or 1 and it specifies whether or not blank
|
||
lines should be printed in between reminders on the same day. The
|
||
default is 1, which causes the blank lines to be printed.
|
||
.PP
|
||
Any of \fIcol\fR, \fIpad\fR or \fIspc\fR can be omitted, providing you
|
||
provide the correct number of commas. Don't use any spaces in the option.
|
||
.RE
|
||
.TP
|
||
.B \-s\fR[\fBa\fR]\fIn\fR
|
||
The \fB\-s\fR option is very similar to the \fB\-c\fR option, except
|
||
that the output calendar is not formatted. It is listed in a "simple
|
||
format" that can be used as input for more sophisticated calendar-drawing
|
||
programs. If \fIn\fR starts with "+", then it is interpreted as a number
|
||
of weeks. This option also implicitly enables the \fB\-o\fR option.
|
||
|
||
If you immediately follow the \fBs\fR with the letter
|
||
\fBa\fR, then \fBRemind\fR displays reminders on the calendar on the
|
||
day they actually occur \fIas well as\fR on any preceding days specified
|
||
by the reminder's \fIdelta\fR.
|
||
.TP
|
||
.B \-p\fR[\fBa\fR][\fBp\fR][\fBp\fR][\fBq\fR][+]\fIn\fR
|
||
The \fB\-p\fR option is very similar to the \fB\-s\fR option, except
|
||
that the output contains additional information for use by a back-end
|
||
such as the \fBRem2PS\fR program, which creates a PostScript calendar,
|
||
and various other back-end programs. If \fIn\fR starts with "+", then
|
||
it specifies a number of weeks rather than a number of months, and
|
||
back-ends are expected to produce weekly calendars. Note that not all
|
||
back-ends support weekly calendars; currently, only \fBrem2pdf\fR and
|
||
\fBrem2html\fR do. Specifying a weekly calendar implicitly enables
|
||
the pure JSON interchange format, similar to \fB\-ppp\fR.
|
||
.RS
|
||
.PP
|
||
The format of the \fB\-p\fR output is described in the \fBrem2ps(1)\fR
|
||
man page. If you immediately follow the \fBp\fR with the letter
|
||
\fBa\fR, then \fBRemind\fR displays reminders on the calendar on the
|
||
day they actually occur \fIas well as\fR on any preceding days specified
|
||
by the reminder's \fIdelta\fR. If you follow the \fBp\fR with another
|
||
\fBp\fR, then \fBRemind\fR uses a more comprehensive JSON-based
|
||
format rather than the "simple calendar" format. This format is
|
||
also documented in the \fBrem2ps(1)\fR man page. Finally, if you use
|
||
three p's, as in \fB\-ppp\fR, then \fBRemind\fR uses a pure JSON
|
||
format, again documented in \fBrem2ps(1)\fR. If you include a \fBq\fR
|
||
letter with this option, then the usual calendar-mode substitution filter
|
||
is disabled and the %"...%" sequences are preserved in the output.
|
||
.PP
|
||
Note that to pass INFO strings to a back-end, you must use \fB\-pp\fR
|
||
or \fB\-ppp\fR. The simpler \fB\-p\fR format is not capable of
|
||
transmitting the INFO strings to the back-end.
|
||
.PP
|
||
The \fB\-p\fR, \fB\-pp\fR and \fB\-ppp\fR options implicitly enable
|
||
the \fB\-o\fR option.
|
||
.PP
|
||
Note that the \fB\-pp\fR or \fB\-ppp\fR options also enable the \fB\-l\fR
|
||
option.
|
||
.RE
|
||
.TP
|
||
.B \-l
|
||
If you use the \-l option in conjunction with the \-p option, then
|
||
\fBRemind\fR outputs additional information for back-end programs such
|
||
as \fBrem2ps\fR. This additional information lets the back-end programs
|
||
correlate a reminder with the source file and line number that produced
|
||
it.
|
||
.TP
|
||
.B \-m
|
||
The \fB\-m\fR option causes the \fB\-c\fR or \fB\-p\fR options to produce
|
||
a calendar whose first column is Monday rather than Sunday.
|
||
(This conforms to the international standard.)
|
||
.TP
|
||
.B \-v
|
||
The \fB\-v\fR option makes the output of \fBRemind\fR slightly more verbose.
|
||
Currently, this causes \fBRemind\fR to echo a bad line in case of an
|
||
error, and to print a security message if a script tests the
|
||
$RunOff system variable.
|
||
.TP
|
||
.B \-o
|
||
The \fB\-o\fR option causes \fBRemind\fR to ignore all \fBONCE\fR
|
||
directives. Note that \fBONCE\fR is also ignored if any of the
|
||
\fB\-c\fR, \fB\-n\fR, \fB\-p\fR, or \fB\-s\fR options is used, if a
|
||
repetition factor \fB*n\fR is used, or if a date other than today's
|
||
date is specified on the command-line.
|
||
.TP
|
||
.B \-t
|
||
The \fB\-t\fR option causes \fBRemind\fR to trigger all non-expired reminders,
|
||
regardless of the \fIdelta\fR supplied for each reminder.
|
||
.TP
|
||
.B \-t\fR\fIn\fR
|
||
If you supply a number \fIn\fR after the \fB\-t\fR option, then
|
||
\fBRemind\fR pretends that every \fBREM\fR command has a delta
|
||
of ++\fIn\fR, regardless of any existing delta.
|
||
.TP
|
||
.B \-tz\fR
|
||
If you supply the letter \fBz\fR after the \fB\-t\fR option, then
|
||
\fBRemind\fR sets all REM statements' deltas to zero, regardless of the
|
||
value supplied in the REM statement itself. In effect, this disables
|
||
all deltas of the form \fB+\fIn\fR and \fB++\fIn\fR.
|
||
.TP
|
||
.B \-tt\fR[\fIn\fR]
|
||
The \fB-tt\fR option causes \fBRemind\fR to assume a default delta of
|
||
\fIn\fR minutes for all timed reminders. If \fB\-tt\fR is given with
|
||
no \fIn\fR, a default delta of 5 minutes is used.
|
||
.TP
|
||
.B \-h
|
||
The \fB\-h\fR option ("hush...") suppresses certain warning and information
|
||
messages. In particular, if no reminders are triggered, this mode
|
||
produces no output.
|
||
.TP
|
||
.B \-a
|
||
The \fB\-a\fR option causes \fBRemind\fR not to immediately trigger
|
||
timed reminders that trigger on the current day. It also causes
|
||
\fBRemind\fR not to place timed reminders in a calendar. If you
|
||
supply two or more \fB\-a\fR options, then \fBRemind\fR \fIwill\fR
|
||
trigger timed reminders that are in the future, but will not trigger
|
||
timed reminders whose time has passed. (Regardless of how many
|
||
\fB\-a\fR options you supply, \fBRemind\fR will not include timed
|
||
reminders in the calendar if at least one \fB\-a\fR option is used.)
|
||
|
||
.TP
|
||
\fB\-q\fR
|
||
The \fB\-q\fR option causes \fBRemind\fR not to queue timed reminders
|
||
for later execution.
|
||
.TP
|
||
\fB\-f\fR
|
||
The \fB\-f\fR option causes \fBRemind\fR to remain in the foreground
|
||
when processing queued reminders, rather than forking off
|
||
a background process to handle them.
|
||
.TP
|
||
.B \-e
|
||
The \fB\-e\fR option diverts error messages (normally sent to the
|
||
standard error stream) to the standard output stream.
|
||
.TP
|
||
.B \-d\fR\fIchars\fR
|
||
The \fB-d\fR option enables certain debugging modes. The \fIchars\fR
|
||
specify which modes to enable:
|
||
.RS
|
||
.TP
|
||
.B e
|
||
Echo all input lines
|
||
.TP
|
||
.B x
|
||
Trace all expression evaluation
|
||
.TP
|
||
.B t
|
||
Display all trigger date computation
|
||
.TP
|
||
.B v
|
||
Dump the variable table after execution of the reminder script
|
||
.TP
|
||
.B l
|
||
Echo lines when displaying error messages
|
||
.TP
|
||
.B f
|
||
Trace the reading of reminder files
|
||
.TP
|
||
.B s
|
||
Trace expression parsing and display the internal expression node
|
||
tree. This is unlikely to be useful unless you are working on
|
||
\fBRemind\fR's expression evaluation engine.
|
||
.TP
|
||
.B h
|
||
Dump hash-table statistics on exit.
|
||
.TP
|
||
.B u
|
||
When \fBRemind\fR exits, print a list of variables that were SET, but
|
||
not subsequently used.
|
||
.RS
|
||
.PP
|
||
Note that the \fBu\fR debugging flag may produce spurious warnings. For
|
||
example, this sequence of commands:
|
||
.PP
|
||
.nf
|
||
DEBUG +u
|
||
SET a 1
|
||
IFTRIG Wed
|
||
MSG a = [a]
|
||
ENDIF
|
||
.fi
|
||
.PP
|
||
will issue a warning about \fBa\fR being unused unless it is run on a
|
||
Wednesday.
|
||
.RE
|
||
.TP
|
||
.B n
|
||
Print debugging information about why \fBRemind\fR considers an expression
|
||
to be "non-constant"
|
||
.TP
|
||
.B q
|
||
Output a TRANSLATE command each time the \fB_()\fR built-in function
|
||
is called or the \fB%(...)\fR substitution sequence is encountered.
|
||
.RE
|
||
.TP
|
||
\fB\-g\fR[\fBa|d\fR[\fBa|d\fR[\fBa|d\fR[\fBa|d\fR]]]]
|
||
Normally, reminders are issued in the order in which they are
|
||
encountered in the reminder script. The \fB\-g\fR option cause
|
||
\fBRemind\fR to sort reminders by date and time prior to issuing them.
|
||
The optional \fBa\fR and \fBd\fR characters specify the sort order
|
||
(ascending or descending) for the date, time and priority fields. See
|
||
the section "SORTING REMINDERS" for more information.
|
||
|
||
Note that \fB\-g\fR is \fIignored\fR if you use the \fB\-n\fR option.
|
||
.TP
|
||
\fB\-b\fR[\fIn\fR]
|
||
Set the time format for the calendar and simple-calendar outputs. \fIN\fR
|
||
can range from 0 to 2, with the default 0. A value of 0 causes times
|
||
to be inserted in 12-hour (am/pm) format. 1 causes times to be inserted
|
||
in 24-hour format, and 2 inhibits the automatic insertion of times in the
|
||
calendar output.
|
||
.TP
|
||
\fB\-x\fR[\fIn\fR]
|
||
Sets the iteration limit for the \fBSATISFY\fR clause of a \fBREM\fR
|
||
command. Defaults to 1000.
|
||
.TP
|
||
\fB\-k\fR\fIcmd\fR
|
||
Instead of simply printing \fBMSG\fR-type
|
||
reminders, this causes them to be passed to the specific \fIcmd\fR.
|
||
You must use '%s' where you want the body to appear, and may need to
|
||
enclose this option in quotes. Note that all shell characters in the
|
||
body of the reminder are escaped with a backslash, and the entire body
|
||
of the reminder is passed as a single argument. Note that this option
|
||
\fBoverrides\fR the \fB\-r\fR option and the \fBRUN OFF\fR command.
|
||
.PP
|
||
.RS
|
||
As an example, suppose you have an X Window program called \fBxmessage\fR that
|
||
pops up a window and displays its invocation arguments. You could use:
|
||
.PP
|
||
.nf
|
||
remind '\-kxmessage %s &' ...
|
||
.fi
|
||
.PP
|
||
to have all of your \fBMSG\fR-type reminders processed using xmessage.
|
||
.PP
|
||
A word of warning: It is very easy to spawn dozens of xmessage
|
||
processes with the above technique. So be very careful. Because all
|
||
shell and whitespace characters are escaped, the program you execute
|
||
with the \fB\-k\fR option must be prepared to handle the entire
|
||
message as a single argument.
|
||
.PP
|
||
If you follow the \fB\-k\fR option with a colon, then the command is applied
|
||
only to queued timed reminders. Normal reminders are handled as usual.
|
||
In the above example, if you want normal reminders to simply be displayed
|
||
as usual, but queued reminders to be sent to notify-send, you could use:
|
||
.PP
|
||
.nf
|
||
remind '\-k:notify-send %s &' ...
|
||
.fi
|
||
.PP
|
||
You use both \fB\-k\fR\fIcmd1\fR and \fB\-k:\fR\fIcmd2\fR to use different
|
||
commands for queued versus non-queued reminders.
|
||
.RE
|
||
.TP
|
||
\fB\-z\fR[\fIn\fR] Runs \fBRemind\fR in "daemon mode". If \fIn\fR
|
||
is supplied, it specifies how often (in minutes) \fBRemind\fR should
|
||
wake up to check if the reminder script has been changed. \fIN\fR
|
||
defaults to 1, and can range from 1 to 60. Note that the use of the
|
||
\fB\-z\fR option also enables the \fB\-f\fR option.
|
||
.PP
|
||
.RS
|
||
If \fBRemind\fR is compiled on a system that supports
|
||
\fBinotify\fR(7), then if the reminder script supplied on the
|
||
command-line is actually a directory, \fBRemind\fR additionally checks
|
||
if all files within that directory have been modified since startup.
|
||
.PP
|
||
If you supply the option \fB\-zj\fR, \fBRemind\fR runs in a
|
||
special mode called \fBserver mode\fR. This is documented
|
||
in the tkremind man page; see tkremind(1). The older server mode
|
||
option \fB\-z0\fR still works, but is deprecated; it uses an ad-hoc
|
||
method to communicate with the client rather than using JSON to communicate
|
||
with the client.
|
||
.RE
|
||
.TP
|
||
\fB\-u\fR\fIname\fR
|
||
Runs \fBRemind\fR with the uid and gid of the user specified by \fIname\fR.
|
||
The option changes the uid and gid as described, and sets the
|
||
environment variables HOME, SHELL and USER to the home directory, shell,
|
||
and user name, respectively, of the specified user. LOGNAME is also
|
||
set to the specified user name. This option is meant for
|
||
use in shell scripts that mail reminders to all users. Note that
|
||
as of \fBRemind\fR 3.00.17, using \fB\-u\fR implies \fB\-r\fR -- the RUN
|
||
directive and shell() functions are disabled. However, if you prefix
|
||
\fIname\fR with a \fB+\fR-sign, then RUN and shell() are \fInot\fR
|
||
disabled. That is, \fB\-uwhatever\fR switches the user to \fBwhatever\fR
|
||
and disables RUN, whereas \fB\-u+whatever\fR switches the user to
|
||
\fBwhatever\fR but leaves RUN enabled.
|
||
.PP
|
||
.RS
|
||
Non-root users can also use the \fB\-u\fR option. However, in this
|
||
case, it only changes the environment variables as described above.
|
||
It does not change the effective uid or gid.
|
||
.RE
|
||
.TP
|
||
\fB\-+\fIusername\fR
|
||
Causes \fBRemind\fR to trust files owned by the user \fIusername\fR.
|
||
Normally, if \fBRemind\fR reads a file that you do not own, it disables
|
||
RUN and the shell() function. This option causes it to also trust files
|
||
owned by \fIusername\fR. You can supply multiple \fB\-+\fR options
|
||
to trust multiple users, up to a limit of 20 trusted users.
|
||
.TP
|
||
\fB-y\fR
|
||
Causes \fBRemind\fR to synthesize a tag for any reminder that lacks a
|
||
TAG clause.
|
||
.TP
|
||
\fB\-i\fR\fIvar\fR\fB=\fR\fIexpr\fR
|
||
Sets the value of the specified \fIvar\fR to \fIexpr\fR, and \fBpreserves\fR
|
||
\fIvar\fR. \fIExpr\fR can be any valid \fBRemind\fR expression. See the
|
||
section "INITIALIZING VARIABLES ON THE COMMAND LINE" for more details. If
|
||
you omit the \fB=\fR\fIexpr\fR part, then \fIvar\fR is initialized to 0.
|
||
In other words, \fB\-i\fIvar\fR is exactly the same as \fB\-i\fIvar\fR\fB=\fR0.
|
||
.TP
|
||
\fB\-i\fR\fIfunc\fR(\fIargs\fR)=\fIdefinition\fR
|
||
Allows you to define a function on the command line.
|
||
.PP
|
||
If you supply a \fIdate\fR on the command line, it must consist of
|
||
\fIday month year\fR, where \fIday\fR is the day of the month,
|
||
\fImonth\fR is at least the first three letters of the English name
|
||
of the month, and \fIyear\fR is a year (all 4 digits) from 1990 to
|
||
about 2075. You can leave out the \fIday\fR, which then defaults to 1.
|
||
.PP
|
||
If you do supply a \fIdate\fR on the command line, then \fBRemind\fR
|
||
uses it, rather than the actual system date, as its notion of "today."
|
||
This lets you create calendars for future months, or test to see how
|
||
your reminders will be triggered in the future. Similarly, you can
|
||
supply a \fItime\fR to set \fBRemind\fR's notion of "now" to a
|
||
particular time. Supplying a \fItime\fR on the command line also
|
||
implicitly enables the \fB\-q\fR option and disables the \fB\-z\fR
|
||
option. The \fItime\fR may be specified in 24-hour format (e.g., 13:20)
|
||
or common "AM/PM" format (1:20pm).
|
||
.PP
|
||
If you would rather specify the date more succinctly, you can supply
|
||
it as YYYY-MM-DD or YYYY/MM/DD. You can even supply a date and
|
||
time on the command line as one argument: YYYY-MM-DD@HH:MM.
|
||
.PP
|
||
In addition, you can supply a \fIrepeat\fR parameter, which has the
|
||
form *\fIrep\fR. This causes \fBRemind\fR to be run \fIrep\fR times,
|
||
with the date incrementing on each iteration. You may have to enclose
|
||
the parameter in quotes to avoid shell expansion. See the subsection
|
||
"Repeated Execution" in the section "CALENDAR MODE" for more
|
||
information.
|
||
|
||
.SH LONG OPTIONS
|
||
|
||
\fBRemind\fR supports the following long options, which \fIare\fR
|
||
case-sensitive:
|
||
|
||
.TP
|
||
.B \-\-version
|
||
The \fB\-\-version\fR option causes \fBRemind\fR to print its version number
|
||
to standard output and then exit.
|
||
.TP
|
||
.B \-\-hide-completed-todos
|
||
In Calendar Mode, \fBRemind\fR normally shows all TODOs. If you supply
|
||
this option, the it will not show TODOs that have been marked as
|
||
completed.
|
||
.TP
|
||
.B \-\-only-todos
|
||
Only issue TODO-type reminders.
|
||
.TP
|
||
.B \-\-only-events
|
||
Do not issue TODO-type reminders.
|
||
.TP
|
||
.B \-\-json
|
||
In Agenda Mode, output JSON instead of the normal text-mode output.
|
||
\fB\-\-json\fR also disables sorting (the \fB-g\fR option) and
|
||
disables queueing (the \fB-q\fR option). See the section "AGENDA MODE
|
||
JSON OUTPUT" for more details. The \fB\-\-json\fR option is ignored
|
||
in Calendar Mode. Note that in JSON mode, the output from any
|
||
\fBRUN\fR-type reminder that would normally appear on standard output
|
||
is redirected to standard error instead; this is so that \fBRUN\fR-type
|
||
reminders don't mess up the output and cause invalid JSON to be produced
|
||
on standard output.
|
||
.TP
|
||
.B \-\-print-errs
|
||
The \fB\-\-print-errs\fR option causes \fBRemind\fR to print all
|
||
possible error messages to standard output and then exit. The
|
||
messages are printed in a format suitable for the first argument of a
|
||
TRANSLATE command. If you TRANSLATE the error messages, then
|
||
\fBRemind\fR will use the translated versions when outputting error
|
||
and warning messages. See also TRANSLATE GENERATE in the section
|
||
"THE TRANSLATION TABLE".
|
||
.RS
|
||
.PP
|
||
Note that if an untranslated message contains printf-style formatting
|
||
sequences like "%s" or "%d", then the translated message \fImust\fR
|
||
contain the same sequences in the same order, or \fBRemind\fR will
|
||
ignore it and use the original untranslated message.
|
||
.RE
|
||
.TP
|
||
.B \-\-print-config-cmd
|
||
This option causes \fBRemind\fR to print the exact \fB./configure\fR
|
||
command that was used when \fBRemind\fR was built. You can use this
|
||
to build a new version of \fBRemind\fR using the same configuration
|
||
as an existing one by running:
|
||
.RS
|
||
.PP
|
||
.nf
|
||
eval `remind --print-config-cmd`
|
||
.fi
|
||
.PP
|
||
from the top-level \fBRemind\fR source directory. (However, it's safer
|
||
to simply run \fBremind --print-config-cmd\fR and then type in the
|
||
command once you've verified that it looks OK.)
|
||
.RE
|
||
|
||
.TP
|
||
.B \-\-print-tokens
|
||
The \fB\-\-print-tokens\fR option causes \fBRemind\fR to print the tokens
|
||
used by the parser, built-in function names, and system variable names
|
||
to standard output and then exit. This output is designed to make it easy
|
||
to create a syntax-highlighting file for various text editors. The output
|
||
can be modified by hand or by a script into a syntax-highlighting file
|
||
with relative ease.
|
||
.TP
|
||
.B \-\-max-execution-time\fR=\fIn\fR
|
||
Limit the total execution time (as measured by the wall clock) to
|
||
\fIn\fR seconds. This is useful if \fBRemind\fR is invoked on
|
||
potentially-untrustworthy files that could attempt to use a lot of
|
||
resources. Note that the limit \fIn\fR is approximate and
|
||
\fBRemind\fR might execute for one or two more seconds before it is
|
||
killed. If \fIn\fR is specified as zero, then no limit is applied, just
|
||
as if the option had not been used at all.
|
||
.RS
|
||
.PP
|
||
If a limit is applied, it applies only to the foreground run of \fBRemind\fR.
|
||
If \fBRemind\fR finishes processing the script and then starts handling
|
||
queued reminders, the time limit is reset to no limit.
|
||
.RE
|
||
.TP
|
||
.B \-\-max-expr-complexity\fR=\fIn\fR
|
||
Limit the total complexity of expression valuation for a given line in a script
|
||
to \fIn\fR nodes. Roughly speaking, each function call, operator, constant,
|
||
variable reference, etc corresponds to one expression node. By default,
|
||
the limit is set to 10000000 (ten million). You can explicitly set it
|
||
to zero if you don't want any limit to apply. The default limit of ten
|
||
million should never be triggered by any sensible Remind script, however,
|
||
and we don't recommend changing the limit.
|
||
.TP
|
||
.B \-\-test
|
||
The \fB\-\-test\fR long option is only for use by the acceptance tests
|
||
run by "make test". Do not use this option in production.
|
||
.TP
|
||
.B \-\-flush
|
||
The \fB\-\-flush\fR long option makes \fBRemind\fR's standard output
|
||
and standard error streams unbuffered. It is mostly used for testing and
|
||
should probably not be used in production.
|
||
.SH REMINDER FILES
|
||
.PP
|
||
\fBRemind\fR uses scripts to control its operation. You can use any
|
||
text editor capable of creating plain-text files to create a
|
||
\fBRemind\fR script. The commands inside a script can range from the
|
||
very simple and almost immediately understandable:
|
||
.PP
|
||
.nf
|
||
REM Mar 31 MSG International Transgender Day of Visibility
|
||
.fi
|
||
.PP
|
||
to the baroque and obscure:
|
||
.PP
|
||
.nf
|
||
REM [date(thisyear, 1, 1) + 180] ++5 OMIT \\
|
||
sat sun BEFORE MSG [ord(thisyear-1980)] payment due %b!
|
||
.fi
|
||
.PP
|
||
A reminder file consists of commands, with one command per line. Several
|
||
lines can be continued using the backslash character, as in the above
|
||
example. In this case, all of the concatenated lines are treated as a
|
||
single line by \fBRemind\fR. Note that if an error occurs, \fBRemind\fR
|
||
reports the line number of the last line of a continued line.
|
||
.PP
|
||
\fBRemind\fR ignores blank lines, and lines beginning with the '#' or ';'
|
||
characters. You can use the semicolon as a comment character if you
|
||
wish to pass a \fBRemind\fR script through the C pre-processor, which
|
||
interprets the '#' character as the start of a pre-processing
|
||
directive.
|
||
.PP
|
||
Note that \fBRemind\fR processes line continuations before anything else.
|
||
For example:
|
||
.PP
|
||
.nf
|
||
# This is a comment \\
|
||
This line is part of the comment because of line continuation \\
|
||
and so on.
|
||
REM MSG This line is not ignored (no \\ above)
|
||
.fi
|
||
.PP
|
||
\fBRemind\fR is not case sensitive; you can generally use any mixture of upper-
|
||
or lower-case for commands, parameters, invocation options, etc.
|
||
.SH THE REM COMMAND
|
||
.PP
|
||
The most powerful command in a \fBRemind\fR script is the \fBREM\fR command.
|
||
This command is responsible for issuing reminders.
|
||
Its syntax is:
|
||
.PP
|
||
.RS
|
||
\fBREM\fR [\fBONCE\fR] [\fIdate_spec\fR]
|
||
[\fIback\fR]
|
||
[\fIdelta\fR]
|
||
[\fIrepeat\fR]
|
||
[\fBTODO\fR]
|
||
[\fBMAX-OVERDUE\fR \fIn\fR]
|
||
[\fBCOMPLETE-THROUGH\fR \fIcomplete_date\fR]
|
||
[\fBPRIORITY\fR \fIprio\fR]
|
||
[\fBSKIP\fR | \fBBEFORE\fR | \fBAFTER\fR]
|
||
[\fBOMIT\fR \fIomit_list\fR]
|
||
[\fBADDOMIT\fR]
|
||
[\fBNOQUEUE\fR]
|
||
[\fBOMITFUNC\fR \fIomit_function\fR]
|
||
[\fBAT\fR \fItime\fR [\fItdelta\fR] [\fItrepeat\fR]]
|
||
[\fBSCHED\fR \fIsched_function\fR]
|
||
[\fBWARN\fR \fIwarn_function\fR]
|
||
[\fBUNTIL\fR \fIexpiry_date\fR | \fBTHROUGH\fR \fIlast_date\fR]
|
||
[\fBSCANFROM\fR \fIscan_date\fR | \fBFROM\fR \fIstart_date\fR]
|
||
[\fBDURATION\fR \fIduration\fR]
|
||
[\fBTAG\fR \fItag\fR]
|
||
[\fBTZ\fR \fItimezone\fR]
|
||
[\fBINFO\fR "\fIinfo_string\fR"]
|
||
\fBMSG\fR | \fBMSF\fR | \fBRUN\fR | \fBCAL\fR | \fBSATISFY\fR |
|
||
\fBSPECIAL\fR \fIspecial\fR | \fBPS\fR | \fBPSFILE\fR
|
||
.I body
|
||
.RE
|
||
.PP
|
||
The parts of the \fBREM\fR command can be specified in any order, except
|
||
that the \fIbody\fR must come immediately after the \fBMSG\fR,
|
||
\fBRUN\fR, \fBCAL\fR, \fBPS\fR, \fBPSFILE\fR or \fBSATISFY\fR keyword.
|
||
The portion of the \fBREM\fR command before the \fBMSG\fR, \fBMSF\fR
|
||
\fBRUN\fR, \fBCAL\fR or \fBSATISFY\fR clause is called a
|
||
\fItrigger\fR.
|
||
.PP
|
||
In earlier versions of \fBRemind\fR, the \fBREM\fR token was optional
|
||
providing that the remainder of the command cannot be mistaken for
|
||
another \fBRemind\fR command. However, this use is deprecated and will
|
||
now cause a warning to be issued. All of your reminder lines should
|
||
be written to start with the REM command.
|
||
.PP
|
||
.B "MSG, MSF, RUN, CAL, SPECIAL, PS and PSFILE"
|
||
.PP
|
||
These keywords denote the \fItype\fR
|
||
of the reminder. (\fBSATISFY\fR is more complicated and will be explained
|
||
later.) A \fBMSG\fR-type reminder normally prints a message to the standard
|
||
output, after passing the \fIbody\fR through a special substitution filter,
|
||
described in the section "THE SUBSTITUTION FILTER." However, if you have
|
||
used the \fB\-k\fR command-line option, then \fBMSG\fR-type reminders are
|
||
passed to the appropriate program. Note that the options \fB\-c\fR,
|
||
\fB\-s\fR, \fB\-p\fR and \fB\-n\fR disable the \fB\-k\fR option.
|
||
.PP
|
||
Earlier versions of \fBRemind\fR let you omit the reminder type,
|
||
in which case it defaulted to \fBMSG\fR. However, this usage is
|
||
deprecated and will cause a warning. Something like:
|
||
.PP
|
||
.nf
|
||
REM 6 January Dianne's Birthday
|
||
.fi
|
||
.PP
|
||
will issue the warning "Missing REM type; assuming MSG"
|
||
|
||
.PP
|
||
The \fBMSF\fR keyword is almost the same as the \fBMSG\fR keyword,
|
||
except that the reminder is formatted to fit into a paragraph-like
|
||
format. Three system variables control the formatting of \fBMSF\fR-type
|
||
reminders - they are \fB$FirstIndent\fR, \fB$SubsIndent\fR and
|
||
\fB$FormWidth\fR. They are discussed in the section "SYSTEM VARIABLES."
|
||
The \fBMSF\fR keyword causes the spacing of your reminder to be altered -
|
||
extra spaces are discarded, and two spaces are placed after periods and
|
||
other characters, as specified by the system variables \fB$EndSent\fR and
|
||
\fB$EndSentIg\fR. Note that if the body of the reminder includes
|
||
newline characters (placed there with the %_ sequence), then the newlines
|
||
are treated as the beginnings of new paragraphs, and the \fB$FirstIndent\fR
|
||
indentation is used for the next line. You can use two consecutive
|
||
newlines to have spaced paragraphs emitted from a single reminder body.
|
||
.PP
|
||
A \fBRUN\fR-type reminder also passes the \fIbody\fR through the
|
||
substitution filter, but then executes the result as a system command.
|
||
A \fBCAL\fR-type reminder is used only to place entries in the
|
||
calendar produced when \fBRemind\fR is run with the \fB\-c\fR,
|
||
\fB\-s\fR or \fB\-p\fR options. When \fBRemind\fR runs a command, it
|
||
sets the command's standard input to come from /dev/null.
|
||
.PP
|
||
A \fBPS\fR or \fBPSFILE\fR-type reminder is used to pass PostScript code
|
||
directly to the printer when producing PostScript calendars. This can
|
||
be used to shade certain calendar entries (see the psshade() function),
|
||
include graphics in the calendar,
|
||
or almost any other purpose you can think of. You
|
||
should not use these types of reminders unless you are an expert PostScript
|
||
programmer. The \fBPS\fR and \fBPSFILE\fR reminders are ignored unless
|
||
\fBRemind\fR is run with the \fB\-p\fR option. See the section
|
||
"More about PostScript" for more details.
|
||
.PP
|
||
A \fBSPECIAL\fR-type reminder is used to pass "out-of-band" information
|
||
from \fBRemind\fR to a calendar-producing back-end. It should be followed
|
||
by a word indicating the type of special data being passed. The type
|
||
of a special reminder depends on the back-end. For the \fBRem2PS\fR
|
||
back-end, \fBSPECIAL PostScript\fR is equivalent to a \fBPS\fR-type
|
||
reminder, and \fBSPECIAL PSFile\fR is equivalent to a \fBPSFILE\fR-type
|
||
reminder. The body of a \fBSPECIAL\fR reminder is obviously dependent
|
||
upon the back-end. A back-end \fImust\fR ignore a \fBSPECIAL\fR that
|
||
it does not recognize.
|
||
.PP
|
||
.B DATE SPECIFICATIONS
|
||
.PP
|
||
A \fIdate_spec\fR consists of zero to four parts.
|
||
These parts are
|
||
.I day
|
||
(day of month),
|
||
.I month
|
||
(month name),
|
||
.I year
|
||
and
|
||
.I weekday.
|
||
.I Month
|
||
and
|
||
.I weekday
|
||
are the English names of months and weekdays. At least the first three
|
||
characters must be used. The following are examples of the various parts of a
|
||
.I date_spec:
|
||
.TP
|
||
.I day:
|
||
1, 22, 31, 14, 3
|
||
.TP
|
||
.I month:
|
||
JANUARY, feb, March, ApR, may, Aug
|
||
.TP
|
||
.I year:
|
||
1990, 1993, 2030. The year can range
|
||
from 1990 to 2075.
|
||
.TP
|
||
.I weekday:
|
||
Monday, tue, Wed, THU, Friday, saturday, sundAy
|
||
.PP
|
||
Note that there can be several
|
||
.I weekday
|
||
components separated by spaces in a
|
||
.I date_spec.
|
||
.PP
|
||
.B INTERPRETATION OF DATE SPECIFICATIONS
|
||
.PP
|
||
The following examples show how date specifications are interpreted.
|
||
.PP
|
||
1. Null date specification - the reminder is triggered every day.
|
||
The trigger date for a specific run is simply the current system date.
|
||
For example:
|
||
.PP
|
||
.nf
|
||
REM MSG This is triggered every time Remind runs
|
||
.fi
|
||
.PP
|
||
2. Only
|
||
.I day
|
||
present. The reminder is triggered on the specified day of each month.
|
||
The trigger date for a particular run is the closest such day to the
|
||
current system date. For example:
|
||
.PP
|
||
.nf
|
||
REM 1 MSG First of every month.
|
||
REM 31 MSG 31st of every month that has 31 days.
|
||
.fi
|
||
.PP
|
||
3. Only
|
||
.I month
|
||
present. The reminder is triggered every day of the specified month.
|
||
Example:
|
||
.PP
|
||
.nf
|
||
REM Feb MSG Every day in February
|
||
.fi
|
||
.PP
|
||
4.
|
||
.I day
|
||
and
|
||
.I month
|
||
present. Examples:
|
||
.PP
|
||
.nf
|
||
REM 6 Jan MSG Every 6th of January
|
||
REM Feb 29 MSG Every 29th of February
|
||
.fi
|
||
.PP
|
||
5. Only
|
||
.I year
|
||
present. Example:
|
||
.PP
|
||
.nf
|
||
REM 1991 MSG Every day in 1991
|
||
.fi
|
||
.PP
|
||
6.
|
||
.I year
|
||
and
|
||
.I day
|
||
present. Examples:
|
||
.PP
|
||
.nf
|
||
REM 1 1990 MSG 1st of every month in 1990
|
||
REM 1992 23 MSG 23rd of every month in 1992
|
||
.fi
|
||
.PP
|
||
7.
|
||
.I year
|
||
and
|
||
.I month
|
||
present. Examples:
|
||
.PP
|
||
.nf
|
||
REM Feb 1991 MSG Every day in Feb 1991
|
||
REM 1992 September MSG Every day in Sept 1992
|
||
.fi
|
||
.PP
|
||
8.
|
||
.I year, month
|
||
and
|
||
.I day
|
||
present. Examples:
|
||
.PP
|
||
.nf
|
||
REM 8 Jan 1991 MSG 8th January 1991.
|
||
REM 1992 March 9 MSG 9th March 1992.
|
||
.fi
|
||
.PP
|
||
9.
|
||
.I weekday
|
||
only. Examples:
|
||
.PP
|
||
.nf
|
||
REM Sat MSG Every Saturday
|
||
REM Mon Tue Wed Thu Fri MSG Every working day
|
||
REM Monday Wednesday MSG Every Monday and Wednesday
|
||
.fi
|
||
.PP
|
||
10.
|
||
.I weekday
|
||
and
|
||
.I day
|
||
present. Examples:
|
||
.PP
|
||
.nf
|
||
REM Sat 1 MSG First Saturday of every month
|
||
REM Mon Tue Wed Thu Fri 15 \\
|
||
MSG 1st working day on or after 15th of every month
|
||
.fi
|
||
.PP
|
||
11.
|
||
.I weekday
|
||
and
|
||
.I month
|
||
present. Examples:
|
||
.PP
|
||
.nf
|
||
REM Mon March MSG Every Monday in March
|
||
REM Mon Tue Wed Thu Fri Feb MSG Every working day in February
|
||
.fi
|
||
.PP
|
||
12.
|
||
.I weekday, month
|
||
and
|
||
.I day
|
||
present. Examples:
|
||
.PP
|
||
.nf
|
||
REM Mon 1 March MSG First Monday in March
|
||
REM Sat Sun 15 July MSG First Sat or Sun on or after 15 July
|
||
.fi
|
||
.PP
|
||
13.
|
||
.I weekday
|
||
and
|
||
.I year
|
||
present. Example:
|
||
.PP
|
||
.nf
|
||
REM Sat Sun 1991 MSG Every Saturday and Sunday in 1991
|
||
.fi
|
||
.PP
|
||
14.
|
||
.I weekday, day
|
||
and
|
||
.I year
|
||
present. Examples:
|
||
.PP
|
||
.nf
|
||
REM Mon 15 1990 MSG 1st Mon after 15th of every month in 1990
|
||
REM Mon Tue Wed Thu Fri 1 1990 \\
|
||
MSG 1st working day of every month in 1990
|
||
.fi
|
||
.PP
|
||
15.
|
||
.I weekday, month
|
||
and
|
||
.I year
|
||
present. Example:
|
||
.PP
|
||
.nf
|
||
REM Mon Wed 1991 Feb MSG Every Mon and Wed in Feb 1991.
|
||
.fi
|
||
.PP
|
||
16.
|
||
.I weekday, day, month
|
||
and
|
||
.I year
|
||
present. Example:
|
||
.PP
|
||
.nf
|
||
REM Mon Tue Wed Thu Fri 28 Oct 1990 \\
|
||
MSG 1st working day on or after 28 October 1990.
|
||
.fi
|
||
.PP
|
||
Note that when both
|
||
.I weekday
|
||
and
|
||
.I day
|
||
are specified,
|
||
.B Remind
|
||
chooses the first date on or after the specified
|
||
.I day
|
||
that also satisfies the
|
||
.I weekday
|
||
constraint. It does this by picking the first date on or after the specified
|
||
.I day
|
||
that is listed in the list of
|
||
.I weekdays.
|
||
Thus, a reminder like:
|
||
.PP
|
||
.nf
|
||
REM Mon Tue 28 Oct 1990 MSG Hi
|
||
.fi
|
||
.PP
|
||
would be issued only on Monday, 29 October, 1990. It would not be issued
|
||
on Tuesday, 30 October, 1990, since the 29th is the first date to satisfy
|
||
the
|
||
.I weekday
|
||
constraints.
|
||
.PP
|
||
.B SHORT-HAND DATE SPECIFICATIONS
|
||
.PP
|
||
In addition to spelling out the day, month and year separately, you
|
||
can specify YYYY-MM-DD or YYYY/MM/DD. For example, the following statements
|
||
are equivalent:
|
||
.PP
|
||
.nf
|
||
REM 5 June 2010 MSG Cool!
|
||
REM 2010-06-05 MSG Cool!
|
||
.fi
|
||
.PP
|
||
You can also specify a date and time as YYYY-MM-DD@HH:MM. These
|
||
statements are equivalent:
|
||
.PP
|
||
.nf
|
||
REM 19 Dec 2010 AT 16:45 MSG Hi
|
||
REM 2010-12-19@16:45 MSG Hi
|
||
.fi
|
||
.PP
|
||
There's one subtlety with short-hand date specifications: The following
|
||
statements are \fInot\fR equivalent:
|
||
.PP
|
||
.nf
|
||
REM 19 Dec 2010 AT 16:45 +60 MSG Hi
|
||
REM 2010-12-19@16:45 +60 MSG Hi
|
||
.fi
|
||
.PP
|
||
In the second statement, the "+60" is a \fIdelta\fR that applies to the
|
||
date rather than a \fItdelta\fR that applies to the time. We recommend
|
||
explicitly using the AT keyword with timed reminders.
|
||
.PP
|
||
.B THE REMIND ALGORITHM
|
||
.PP
|
||
\fBRemind\fR uses the following algorithm to compute a trigger date:
|
||
Starting from the current date, it examines each day, one at a time, until
|
||
it finds a date that satisfies the date specification, or proves to
|
||
itself that no such date exists. (Actually, \fBRemind\fR merely
|
||
\fIbehaves\fR as if it used this algorithm; it would be much too slow
|
||
in practice. Internally, \fBRemind\fR uses much faster techniques to
|
||
calculate a trigger date.) See DETAILS ABOUT TRIGGER COMPUTATION for
|
||
more information.
|
||
.PP
|
||
.B BACKWARD SCANNING
|
||
.PP
|
||
Sometimes, it is necessary to specify a date as being a set amount of
|
||
time before another date. For example, the last Monday in a given
|
||
month is computed as the first Monday in the next month, minus 7 days.
|
||
The \fIback\fR specification in the reminder is used in this case:
|
||
.PP
|
||
.nf
|
||
REM Mon 1 \-7 MSG Last Monday of every month.
|
||
.fi
|
||
.PP
|
||
A \fIback\fR is specified with one or two dashes followed by an integer.
|
||
This causes \fBRemind\fR to move "backwards" from what would normally be the
|
||
trigger date. The difference between \-\-7 and \-7 will be explained
|
||
when the \fBOMIT\fR keyword is described.
|
||
.PP
|
||
.B ADVANCE WARNING
|
||
.PP
|
||
For some reminders, it is appropriate to receive advance warning of the
|
||
event. For example, you may wish to be reminded of someone's birthday
|
||
several days in advance. The \fIdelta\fR portion of the \fBREM\fR command
|
||
achieves this. It is specified as one or two "+" signs followed by a number
|
||
\fIn\fR. Again, the difference between the "+" and "++" forms will
|
||
be explained under the \fBOMIT\fR keyword.
|
||
\fBRemind\fR will trigger the reminder on computed trigger date, as well as
|
||
on each of the \fIn\fR days before the event. Here are some examples:
|
||
.PP
|
||
.nf
|
||
REM 6 Jan +5 MSG Remind me of birthday 5 days in advance.
|
||
.fi
|
||
.PP
|
||
The above example would be triggered every 6th of January, as well as the
|
||
1st through 5th of January.
|
||
.PP
|
||
.B PERIODIC REMINDERS
|
||
.PP
|
||
We have already seen some built-in mechanisms for certain types of
|
||
periodic reminders. For example, an event occurring every Wednesday
|
||
could be specified as:
|
||
.PP
|
||
.nf
|
||
REM Wed MSG Event!
|
||
.fi
|
||
.PP
|
||
However, events that do not repeat daily, weekly, monthly or yearly require
|
||
another approach. The \fIrepeat\fR component of the \fBREM\fR command
|
||
fills this need. To use it, you must completely specify a date (year, month
|
||
and day, and optionally weekday); this is the start date of the
|
||
repetition period. The \fIrepeat\fR component is an asterisk
|
||
followed by a number specifying the repetition period in days.
|
||
.PP
|
||
For example, suppose you get paid every second Wednesday, and your
|
||
last payday was Wednesday, 28 October, 1992. You can use:
|
||
.PP
|
||
.nf
|
||
REM 28 Oct 1992 *14 MSG Payday
|
||
.fi
|
||
.PP
|
||
This issues the reminder every 14 days, starting from 28 Oct 1992.
|
||
You can use \fIdelta\fR and \fIback\fR with \fIrepeat.\fR Note,
|
||
however, that the \fIback\fR is used only to compute the starting
|
||
date; thereafter, the reminder repeats with the specified
|
||
period. Similarly, if you specify a weekday, it is used only to calculate
|
||
the starting date, and does not affect the repetition period.
|
||
.PP
|
||
.B SCANFROM \fRand\fB FROM
|
||
.PP
|
||
The \fBSCANFROM\fR and \fBFROM\fR keywords are for advanced \fBRemind\fR programmers
|
||
only, and will be explained in the section "DETAILS ABOUT TRIGGER COMPUTATION"
|
||
near the end of this manual. Note that \fBSCANFROM\fR is available only
|
||
in versions of \fBRemind\fR from 03.00.04 up. \fBFROM\fR is available only
|
||
from 03.01.00 and later.
|
||
.PP
|
||
.B PRIORITY
|
||
.PP
|
||
The \fBPRIORITY\fR keyword must be followed by a number from 0 to 9999.
|
||
It is used in calendar mode and when sorting reminders. If two reminders
|
||
have the same trigger date and time, then they are sorted by priority.
|
||
If the \fBPRIORITY\fR keyword is not supplied, a default priority of 5000
|
||
is used. (This default can be changed by adjusting the system variable
|
||
\fB$DefaultPrio\fR. See the section "SYSTEM VARIABLES" for more
|
||
information.)
|
||
.PP
|
||
.B EXPIRY DATES
|
||
.PP
|
||
Some reminders should be issued periodically for a certain time, but then
|
||
expire. For example, suppose you have a class every Friday, and that your
|
||
last class is on 11 December 1992. You can use:
|
||
.PP
|
||
.nf
|
||
REM Fri UNTIL 11 Dec 1992 MSG Class today.
|
||
.fi
|
||
.PP
|
||
Another example: Suppose you have jury duty from 30 November 1992 until
|
||
4 December 1992. The following reminder will issue the message every day
|
||
of your jury duty, as well as 2 days ahead of time:
|
||
.PP
|
||
.nf
|
||
REM 1992-11-30 *1 +2 UNTIL 1992-12-04 MSG Jury duty
|
||
.fi
|
||
.PP
|
||
Note that the \fIrepeat\fR of *1 is necessary; without it, the reminder
|
||
would be issued only on 30 November (and the two days preceding.)
|
||
.PP
|
||
As a special case, you can use the \fBTHROUGH\fR keyword instead of
|
||
*1 and \fBUNTIL\fR. The following two \fBREM\fR commands are equivalent:
|
||
.PP
|
||
.nf
|
||
REM 1992-11-30 *1 +2 UNTIL 1992-12-04 MSG Jury duty
|
||
|
||
REM 1992-11-30 +2 THROUGH 1992-12-04 MSG Jury duty
|
||
.fi
|
||
.PP
|
||
If you have an expiry date via the use of \fBTHROUGH\fR or \fBUNTIL\fR,
|
||
then \fBRemind\fR will \fInever\fR trigger the reminder after the expiry
|
||
date. For example, if you have this:
|
||
.PP
|
||
.nf
|
||
OMIT 2021-01-08
|
||
REM 2021-01-01 THROUGH 2021-01-08 AFTER MSG Test
|
||
.fi
|
||
.PP
|
||
the reminder will not be triggered on 2021-01-08, and nor will it be
|
||
triggered on 2021-01-09; even though the AFTER keyword would normally
|
||
move the 8th's reminder to the 9th, the expiry date of 2021-01-08
|
||
overrides that.
|
||
.PP
|
||
.B THE ONCE KEYWORD
|
||
.PP
|
||
Sometimes, it is necessary to ensure that reminders are run only once
|
||
on a given day. For example, compare the following two reminders:
|
||
.PP
|
||
.nf
|
||
REM Fri RUN do_backup
|
||
REM Fri ONCE RUN do_backup
|
||
.fi
|
||
.PP
|
||
The first will be run every time you invoke \fBRemind\fR on a Friday,
|
||
whereas the second will be run only the first time you invoke
|
||
\fBRemind\fR on a given Friday.
|
||
.PP
|
||
If you run \fBRemind\fR from your .login script, for example, and log
|
||
in several times per day, the \fIdo_backup\fR program in the first
|
||
reminder will be run each time you log in. If, however, you use the
|
||
\fBONCE\fR keyword in the reminder, the \fBRemind\fR checks the last
|
||
access date of the reminder script. If it is the same as the current
|
||
date, \fBRemind\fR assumes that it has already been run, and will not
|
||
issue reminders containing the \fBONCE\fR keyword.
|
||
.PP
|
||
Note that if you view or edit your reminder script, the last access date
|
||
will be updated, and the \fBONCE\fR keyword will not operate properly.
|
||
You can fix this by setting a timestamp file for \fBRemind\fR to track
|
||
the last-run date; see the documentation of \fB$OnceFile\fR in the
|
||
\fBSYSTEM VARIABLES\fR section. If you use standard input as your
|
||
\fBRemind\fR input file, then you \fImust\fR use \fB$OnceFile\fR for the
|
||
\fBONCE\fR keyword to work properly.
|
||
.PP
|
||
If you start \fBRemind\fR with the \fB\-o\fR option, then the \fBONCE\fR
|
||
keyword will be ignored and any \fB$OnceFile\fR will be ignored.
|
||
.PP
|
||
.B LOCALLY OMITTING WEEKDAYS
|
||
.PP
|
||
The \fBOMIT\fR portion of the \fBREM\fR command is used to "omit" certain
|
||
days when counting the \fIdelta\fR or \fIback\fR. It is specified using
|
||
the keyword \fBOMIT\fR followed by a list of weekdays. Its action is
|
||
best illustrated with examples:
|
||
.PP
|
||
.nf
|
||
REM 1 +1 OMIT Sat Sun MSG Important Event
|
||
.fi
|
||
.PP
|
||
This reminder is normally triggered on the first of every month, as well
|
||
as the day preceding it. However, if the first of the month falls on a
|
||
Sunday or Monday, then the reminder is triggered starting from the
|
||
previous Friday. This is because the \fIdelta\fR of +1 does not count
|
||
Saturday or Sunday when it counts backwards from the trigger date to
|
||
determine how much advance warning to give.
|
||
.PP
|
||
Contrast this with the use of "++1" in the above command. In this case,
|
||
the reminder is triggered on the first of each month, as well as the day
|
||
preceding it. The omitted days are counted.
|
||
.PP
|
||
.nf
|
||
REM 1 \-1 OMIT Sat Sun MSG Last working day of month
|
||
.fi
|
||
.PP
|
||
Again, in the above example, the \fIback\fR of \-1 normally causes the
|
||
trigger date to be the last day of the month. However, because of the
|
||
\fBOMIT\fR clause, if the first of the month falls on a Sunday or Monday,
|
||
the trigger date is moved backwards past the weekend to Friday. (If you
|
||
have globally omitted holidays, the reminder will be moved back past them,
|
||
also. See "The OMIT command" for more details.)
|
||
.PP
|
||
By comparison, if we had used "\-\-1", the reminder would be triggered on
|
||
the last day of the month, regardless of the \fBOMIT\fR.
|
||
.PP
|
||
If you locally omit weekdays but also have globally-omitted weekdays, then
|
||
the list of omitted weekdays is the union of the two. Consider this
|
||
example:
|
||
.PP
|
||
.nf
|
||
OMIT Sat Sun
|
||
REM 15 OMIT Fri Sat MSG Whatever
|
||
.fi
|
||
.PP
|
||
In the REM command, the effective list of omitted weekdays will
|
||
be Friday, Saturday and Sunday.
|
||
.PP
|
||
.B COMPUTED LOCAL OMITS
|
||
.PP
|
||
The \fBOMITFUNC\fR phrase of the \fBREM\fR command allows you to
|
||
supply a function that determines whether or not a date is omitted.
|
||
Note that \fBOMITFUNC\fR must be given just the name of a user-defined
|
||
function; it can't take an arbitrary expression or the name of a built-in
|
||
function.
|
||
.PP
|
||
The function is passed a single parameter of type \fBDATE\fR, and must
|
||
return a non-zero integer if the date is considered "omitted" and 0
|
||
otherwise. Here's an example:
|
||
.PP
|
||
.nf
|
||
FSET _third(x) (day(x) % 3) || \\
|
||
(wkdaynum(x) == 0) || \\
|
||
(wkdaynum(x) == 6)
|
||
REM OMITFUNC _third AFTER MSG Working day divisible by 3
|
||
.fi
|
||
.PP
|
||
In the example above, the reminder is triggered every Monday to Friday whose
|
||
day-of-month number is divisible by three. Here's how it works:
|
||
.TP
|
||
.B o
|
||
The \fBOMITFUNC _third\fR portion causes all days for which \fB_third(x)\fR
|
||
returns non-zero to be considered "omitted". This causes all days whose
|
||
day-of-month number is \fInot\fR a multiple of three to be omitted. Note
|
||
that _third also returns non-zero if the weekday is Sunday or Saturday.
|
||
.TP
|
||
.B o
|
||
The \fBAFTER\fR keyword causes the reminder to be moved after a block of
|
||
omitted days.
|
||
.PP
|
||
The combination of OMITFUNC and AFTER keyword causes the reminder to
|
||
be issued on all days whose day-of-month number is divisible by three,
|
||
but not on Saturday or Sunday.
|
||
.PP
|
||
Note that if you use \fBOMITFUNC\fR, then a local \fBOMIT\fR is
|
||
\fIignored\fR as are \fIall global OMITs\fR. If you want to omit specific
|
||
weekdays, your omit function will need to test for them specifically. If
|
||
you want to take into account the global \fBOMIT\fR context, then your omit
|
||
function will need to test for that explicitly (using the \fBisomitted()\fR
|
||
function.)
|
||
.PP
|
||
Note that an incorrect \fBOMITFUNC\fR might cause all days to be considered
|
||
omitted. For that reason, when \fBRemind\fR searches through omitted days,
|
||
it terminates the search after the \fBSATISFY\fR iteration limit
|
||
(command-line option \fB\-x\fR.)
|
||
.PP
|
||
.B ADDING TRIGGER DATES TO THE OMIT CONTEXT
|
||
.PP
|
||
If the \fBADDOMIT\fR keyword appears in a \fBREM\fR command, then
|
||
the trigger date (if one could be calculated) is automatically
|
||
added to the list of global OMITs.
|
||
.PP
|
||
The command:
|
||
.PP
|
||
.nf
|
||
REM ... whatever ... ADDOMIT MSG Foo
|
||
.fi
|
||
.PP
|
||
is identical in behavior to the sequence:
|
||
.PP
|
||
.nf
|
||
REM ... whatever ... SATISFY 1
|
||
IF trigvalid()
|
||
OMIT [trigdate()] MSG Foo
|
||
ENDIF
|
||
.fi
|
||
.PP
|
||
.B TIMED REMINDERS
|
||
.PP
|
||
Timed reminders are those that have an \fBAT\fR keyword followed
|
||
by a \fItime\fR and optional \fItdelta\fR and \fItrepeat\fR. The \fItime\fR
|
||
may be specified in 24-hour format, with 0:00 representing midnight,
|
||
12:00 representing noon, and 23:59 representing one minute to midnight.
|
||
Alternatively, it may be specified in common "AM/PM" format; in this case,
|
||
the hour must range from 1 to 12. 12:00am represents midnight, 12:00pm
|
||
represents noon, and 11:59pm represents one minute to midnight. The "am"
|
||
and "pm" portions are case-insensitive and the "m" is optional.
|
||
.PP
|
||
You can use either a colon or a period to separate the hours from the
|
||
minutes. That is, 13:39 and 13.39 are equivalent.
|
||
.PP
|
||
\fBRemind\fR treats timed reminders specially. If the trigger date
|
||
for a timed reminder is the same as the current system date, the
|
||
reminder is queued for later activation. When \fBRemind\fR has
|
||
finished processing the reminder file, it puts itself in the
|
||
background, and activates timed reminders when the system time reaches
|
||
the specified time. Note that if you use the \fBNOQUEUE\fR modifier
|
||
in the \fBREM\fR command, then this queuing and background activation
|
||
is \fInot\fR performed. \fBNOQUEUE\fR is useful if you want a time
|
||
to be associated with a reminder (e.g., in the calendar) but are not
|
||
interested in a popup reminder happening at the specified time.
|
||
|
||
.PP
|
||
If the trigger date is \fInot\fR the same as the system date, the reminder
|
||
is not queued.
|
||
.PP
|
||
For example, the following reminder, triggered every working day,
|
||
will emit a message telling you to
|
||
leave at 5:00pm:
|
||
.PP
|
||
.nf
|
||
REM Mon Tue Wed Thu Fri AT 17:00 MSG Time to leave!
|
||
.fi
|
||
.PP
|
||
The following reminder will be triggered on Thursdays and Fridays,
|
||
but will only be queued on Fridays:
|
||
.PP
|
||
.nf
|
||
REM Fri ++1 AT 1:00PM MSG Lunch at 1pm Friday.
|
||
.fi
|
||
.PP
|
||
The \fItdelta\fR and \fItrepeat\fR have the same form as a \fIrepeat\fR
|
||
and \fIdelta\fR, but are specified in minutes. For example, this reminder
|
||
will be triggered at 12:00pm as well as 45 minutes before:
|
||
.PP
|
||
.nf
|
||
REM AT 12:00 +45 MSG Example
|
||
.fi
|
||
.PP
|
||
The following will be issued starting at 10:45, every half hour until 11:45,
|
||
and again at noon.
|
||
.PP
|
||
.nf
|
||
REM AT 12:00 +75 *30 MSG Example2
|
||
.fi
|
||
.PP
|
||
The "+75" means that the reminder is issued starting 75 minutes before noon;
|
||
in other words, at 10:45. The *30 specifies that the reminder is subsequently
|
||
to be issued every 30 minutes. Note that the reminder is always issued at
|
||
the specified time, even if the \fItdelta\fR is not a multiple of the
|
||
\fItrepeat\fR. So the above example is issued at 10:45am, 11:15am, 11:45am,
|
||
and 12:00pm. Note that in the time specification, there is no distinction
|
||
between the "+" and "++" forms of \fItdelta\fR.
|
||
.PP
|
||
Normally, \fBRemind\fR will issue timed reminders as it processes the reminder
|
||
script, as well as queuing them for later. If you do not want \fBRemind\fR to
|
||
issue the reminders when processing the script, but only to queue them
|
||
for later, use the \fB\-a\fR command-line option. If you do not want
|
||
reminders to be queued for later, use the \fB\-q\fR command-line
|
||
option.
|
||
.PP
|
||
Normally, \fBRemind\fR forks a background process to handle queued reminders.
|
||
If you want \fBRemind\fR to remain in the foreground, use the \fB\-f\fR
|
||
command-line option. This is useful, for example, in .xinitrc
|
||
scripts, where you can use the command:
|
||
.PP
|
||
.nf
|
||
remind \-fa myreminders &
|
||
.fi
|
||
.PP
|
||
This ensures that when you exit X-Windows, the \fBRemind\fR process is killed.
|
||
.PP
|
||
.B WARNING ABOUT TIMED REMINDERS
|
||
.PP
|
||
Note: If you use user-defined functions or variables (described later)
|
||
in the bodies of timed reminders, then when the timed reminders are
|
||
activated, the variables and functions have the definitions that were
|
||
in effect at the end of the reminder script. These definitions may
|
||
\fInot\fR necessarily be those that were in effect at the time the reminder
|
||
was queued. In addition, the OMIT context is whatever was in effect at
|
||
the end of the reminder script, which may not necessarily be the same
|
||
as when the \fBREM\fR command was first processed.
|
||
.PP
|
||
.B THE SCHED AND WARN KEYWORDS
|
||
.PP
|
||
The \fBSCHED\fR keyword allows more precise control over the triggering
|
||
of timed reminders, and the \fBWARN\fR keyword allows precise control
|
||
over the advance triggering of all types of reminders.
|
||
However, discussion must be deferred until after
|
||
expressions and user-defined functions are explained. See the subsection
|
||
"PRECISE SCHEDULING" further on.
|
||
.PP
|
||
.B TAG, INFO AND DURATION
|
||
.PP
|
||
The \fBTAG\fR keyword lets you "tag" certain reminders. This facility
|
||
is used by certain back-ends or systems built around \fBRemind\fR,
|
||
such as \fBTkRemind\fR. These back-ends have specific rules about
|
||
tags; see their documentation for details.
|
||
.PP
|
||
The \fBTAG\fR keyword is followed by a tag consisting of up to
|
||
48 characters. You can have as many TAG clauses as you like in
|
||
a given REM statement. A tag can contain any character except for
|
||
whitespace and a comma.
|
||
.PP
|
||
If you supply the \fB\-y\fR option to \fBRemind\fR, then any
|
||
reminder that lacks a \fBTAG\fR will have one synthesized. The
|
||
synthesized tag consists of the characters "__syn__" followed
|
||
by the hexadecimal representation of the MD5 sum of the REM
|
||
command line. This lets you give a more-or-less unique identifier
|
||
to each distinct REM command.
|
||
.PP
|
||
The \fBINFO\fR keyword is similar to \fBTAG\fR but is intended to convey
|
||
metadata about an event, such as its location. Back-ends will have their
|
||
own rules about which \fIinfo_string\fRs they recognize, and must ignore
|
||
\fIinfo_string\fRs they don't recognize. Note that \fBINFO\fR must
|
||
be followed by a quoted string; you can include newlines in the string
|
||
by supplying them as "\\n".
|
||
.PP
|
||
An INFO string \fImust\fR be of the form "Header: Value". The header
|
||
can consist of any printable character, but cannot contain whitespace.
|
||
The value can consist of any characters you like. Space may not
|
||
appear before the colon, but can appear afterwards; such space is not
|
||
considered to be part of the value. If there is more than one INFO
|
||
string for a given reminder, there cannot be any duplicate headers.
|
||
Case is ignored when determining if a header is a duplicate of an
|
||
existing one.
|
||
.PP
|
||
For example, a hypothetical back-end might let you set the location
|
||
and description of a reminder like this:
|
||
.PP
|
||
.nf
|
||
REM 26 Feb 2025 INFO "Location: Boardroom #2" \\
|
||
INFO "Description: Go over latest pull requests" \\
|
||
MSG Engineering meeting
|
||
.fi
|
||
.PP
|
||
While back-ends can choose which INFO strings to support, all back-ends
|
||
should endeavor to support three standard ones: \fBLocation:\fR,
|
||
\fBDescription:\fR and \fBUrl:\fR. TkRemind supports all three of these,
|
||
turning reminders with a \fBUrl:\fR INFO string into hyper-links, and
|
||
popping up information windows for the \fBLocation:\fR and \fBDescription:\fR
|
||
INFO strings. \fBLocation:\fR and \fBUrl:\fR are self-explanatory;
|
||
\fBDescription:\fR is meant for a longer, more in-depth description
|
||
of the reminder than the summary that is normally displayed.
|
||
.PP
|
||
The \fBDURATION\fR keyword makes sense only for timed reminders; it
|
||
specifies the duration of an event. For example, if you have a
|
||
90-minute meeting starting at 1:00pm, you could use any of the following:
|
||
.PP
|
||
.nf
|
||
REM 5 March 2021 AT 13:00 DURATION 1:30 MSG Meeting
|
||
REM 5 March 2021 AT 13:00 DURATION 90 MSG Meeting
|
||
REM 5 March 2021 AT 1:00pm DURATION 1:30 MSG Meeting
|
||
REM 5 March 2021 AT 1:00pm DURATION 90 MSG Meeting
|
||
.fi
|
||
.PP
|
||
For long-duration reminders, it is convenient to use expressions
|
||
to simplify writing the DURATION. For example, if you are away
|
||
from 20 Feb 2023 through 23 Feb 2023 (a total of 4 days) you
|
||
could write:
|
||
.PP
|
||
.nf
|
||
REM 20 Feb AT 00:00 DURATION [4*24]:00 MSG away
|
||
REM 20 Feb AT 00:00 DURATION [4*24*60] MSG away
|
||
.fi
|
||
.PP
|
||
Note that \fIduration\fR is specified either as
|
||
\fIhours\fR:\fIminutes\fR or just as \fIminutes\fR specified as an
|
||
\fIinteger\fR.
|
||
.PP
|
||
If you specify a duration of 00:00 or 0, then \fBRemind\fR behaves
|
||
exactly as if no \fBDURATION\fR at all had been present. Although
|
||
durations specified as \fIhours\fR:\fIminutes\fR look superficially like a
|
||
time-of-day, they are not; the \fIhours\fR component is not limited
|
||
to the range 00-23.
|
||
|
||
.PP
|
||
.SH SYNTACTIC SUGAR FOR REM
|
||
.PP
|
||
The REM command has syntactic sugar to let you express common
|
||
reminders. The following pairs of reminders are equivalent:
|
||
.PP
|
||
.nf
|
||
REM First Monday April MSG Foo
|
||
REM Mon 1 April MSG Foo
|
||
|
||
REM Second Monday May MSG Bar
|
||
REM Mon 8 May MSG Bar
|
||
|
||
REM Third Monday MSG Third Monday of every month
|
||
REM Mon 15 MSG Third Monday of every month
|
||
|
||
REM Fourth Sunday June 2025 MSG Fourth Sunday in June 2025
|
||
REM Sun 22 June 2025 MSG Fourth Sunday in June 2025
|
||
|
||
REM Last Monday MSG Last Monday of every month
|
||
REM Mon 1 --7 MSG Last Monday of every month
|
||
|
||
REM Last Monday April MSG Last Monday of every April
|
||
REM Mon 1 May --7 MSG Last Monday of every April
|
||
|
||
REM Last Monday December 2025 MSG Last Monday of Dec 2025
|
||
REM Monday 1 Jan 2026 --7 MSG Last Monday of Dec 2025
|
||
.fi
|
||
.PP
|
||
Note that \fBLast\fR effectively adjusts the month and year, if necessary, to
|
||
make the reminder trigger on the correct date.
|
||
.PP
|
||
The keyword \fBIN\fR is completely ignored, so you can write (for example):
|
||
.PP
|
||
.nf
|
||
REM Second Monday in May MSG foo
|
||
REM Last Monday in December 2025 MSG Bar
|
||
.fi
|
||
.PP
|
||
An alternate form of \fIback\fR makes writing reminders easier.
|
||
The following groups of reminders are equivalent:
|
||
.PP
|
||
.nf
|
||
REM ~~1 MSG Last day of every month
|
||
REM Lastday MSG Last day of every month
|
||
REM 1 --1 MSG Last day of every month
|
||
|
||
REM May ~~1 MSG Last day of May
|
||
REM Lastday May MSG Last day of May
|
||
REM 1 June --1 MSG Last day of May
|
||
|
||
REM Dec 2025 ~~1 MSG Last day of December 2025
|
||
REM Lastday Dec 2025 MSG Last day of December 2025
|
||
REM 1 Jan 2026 --1 MSG Last day of December 2025
|
||
|
||
REM Apr ~1 OMIT SAT SUN MSG Last workday of April
|
||
REM Lastworkday April OMIT SAT SUN MSG Last workday of April
|
||
REM 1 May -1 OMIT SAT SUN MSG Last workday of April
|
||
|
||
REM Apr ~~7 MSG Seventh-last day of April
|
||
REM 1 May --7 MSG Seventh-last day of April
|
||
|
||
REM Apr ~2 OMIT SAT SUN MSG Second-last workday of April
|
||
REM 1 May -2 OMIT SAT SUN MSG Second-last workday of April
|
||
.fi
|
||
.PP
|
||
As we see, "Lastday" is equivalent to ~~1 and "Lastworkday" to ~1.
|
||
.PP
|
||
Note that the First/Second/Third/Fourth/Last keywords and the ~ and ~~ form
|
||
of \fIback\fR imply a value for the day of the month; as such, they cannot
|
||
be combined with a day. Additionally, First/Second/Third/Fourth/Last
|
||
must have at least one weekday name. The following are illegal:
|
||
.PP
|
||
.nf
|
||
REM First Monday 3 June MSG Huh?
|
||
REM April 3 ~~1 MSG What?
|
||
REM Second June MSG Where's the weekday???
|
||
.fi
|
||
.PP
|
||
.SH THE SUBSTITUTION FILTER
|
||
.PP
|
||
Before being processed, the body of a
|
||
.B REM
|
||
command is passed through a substitution filter. The filter scans for
|
||
sequences "%x" (where "x" is any letter and certain other characters)
|
||
and performs substitutions as
|
||
shown below. (All dates refer to the trigger date of the reminder.)
|
||
.TP
|
||
.B %a
|
||
is replaced with "on \fIweekday, day month, year\fR"
|
||
.RS
|
||
For example, consider the reminder:
|
||
.PP
|
||
REM 18 Oct 1990 +4 MSG Meeting with Bob %a.
|
||
.PP
|
||
On 16 October 1990, it would print "Meeting with Bob on Thursday, 18 October,
|
||
1990."
|
||
.PP
|
||
On 17 October 1990, it would print "Meeting with Bob tomorrow."
|
||
.PP
|
||
On 18 October 1990, it would print "Meeting with Bob today."
|
||
.RE
|
||
.TP
|
||
.B %b
|
||
is replaced with "in \fIdiff\fR day's time" where
|
||
.I diff
|
||
is the
|
||
.B actual
|
||
number of days between the current date and the trigger date.
|
||
(\fBOMITs\fR have no effect.)
|
||
.RS
|
||
For example, consider:
|
||
.PP
|
||
REM 18 Oct 1990 +4 MSG Meeting with Bob %b.
|
||
.PP
|
||
On 16 October 1990, it would print "Meeting with Bob in 2 days' time."
|
||
.PP
|
||
On 17 October 1990, it would print "Meeting with Bob tomorrow."
|
||
.PP
|
||
On 18 October 1990, it would print "Meeting with Bob today."
|
||
.RE
|
||
.TP
|
||
.B %c
|
||
is replaced with "on \fIweekday\fR"
|
||
.RS
|
||
Example: REM 18 Oct 1990 +4 MSG Meeting with Bob %c.
|
||
.PP
|
||
On 16 October 1990, it would print "Meeting with Bob on Thursday."
|
||
.PP
|
||
On 17 October 1990, it would print "Meeting with Bob tomorrow."
|
||
.PP
|
||
On 18 October 1990, it would print "Meeting with Bob today."
|
||
.RE
|
||
.TP
|
||
.B %d
|
||
is replaced with "\fIday\fR", the day of the month.
|
||
.TP
|
||
.B %e
|
||
is replaced with "on \fIdd-mm-yyyy\fR"
|
||
.TP
|
||
.B %f
|
||
is replaced with "on \fImm-dd-yyyy\fR"
|
||
.TP
|
||
.B %g
|
||
is replaced with "on \fIweekday, day month\fR"
|
||
.TP
|
||
.B %h
|
||
is replaced with "on \fIdd-mm\fR"
|
||
.TP
|
||
.B %i
|
||
is replaced with "on \fImm-dd\fR"
|
||
.TP
|
||
.B %j
|
||
is replaced with "on \fIweekday, month day-th, year\fR" This form appends the
|
||
characters "st", "nd", "rd" or "th" to the day of the month, as appropriate.
|
||
.TP
|
||
.B %k
|
||
is replaced with "on \fIweekday, month day-th\fR"
|
||
.TP
|
||
.B %l
|
||
is replaced with "on \fIyyyy-mm-dd\fR"
|
||
.TP
|
||
.B %m
|
||
is replaced with "\fImonth\fR", the name of the month.
|
||
.TP
|
||
.B %n
|
||
is replaced with the number (1 to 12) of the month.
|
||
.TP
|
||
.B %o
|
||
is replaced with " (today)" if and only if the current system date is the same
|
||
as the date being used by
|
||
.B Remind
|
||
as the current date. Recall that you can specify a date for
|
||
.B Remind
|
||
to use on the command line. This substitution is not generally useful in a
|
||
.B REM
|
||
command, but is useful in a
|
||
.B BANNER
|
||
command. (See "The BANNER Command.")
|
||
.TP
|
||
.B %p
|
||
is replaced with "s" if the
|
||
.I diff
|
||
between the current date and the trigger date is not 1. You can use this
|
||
to construct reminders like:
|
||
.RS
|
||
REM 1 Jan +4 MSG %x day%p to go before New Year!
|
||
.RE
|
||
.TP
|
||
.B %q
|
||
is replaced with "'s" if the
|
||
.I diff
|
||
between the trigger date and the current date is 1. Otherwise, it is replaced
|
||
with "s'" This can be used as follows:
|
||
.RS
|
||
REM 1 Jan +4 MSG New Year in %x day%q time!
|
||
.RE
|
||
.TP
|
||
.B %r
|
||
is replaced with the day of the month (01 to 31) padded with a leading zero
|
||
if needed to pad to two digits.
|
||
.TP
|
||
.B %s
|
||
is replaced with "st", "nd", "rd" or "th" depending on the day of the month.
|
||
.TP
|
||
.B %t
|
||
is replaced with the number of the month (01 to 12) padded to two digits
|
||
with a leading zero.
|
||
.TP
|
||
.B %u
|
||
is replaced with "on \fIweekday, day-th month, year\fR" This is similar
|
||
to
|
||
.B %a
|
||
except that "st", "nd", "rd" or "th" is added to the
|
||
.I day
|
||
as appropriate.
|
||
.TP
|
||
.B %v
|
||
is replaced with "on \fIweekday, day-th month\fR"
|
||
.TP
|
||
.B %w
|
||
is replaced with "\fIweekday\fR", the name of the day of the week.
|
||
.TP
|
||
.B %x
|
||
is replaced with the
|
||
.I diff
|
||
between the current date and the trigger date. The
|
||
.I diff
|
||
is defined as the actual number of days between these two dates;
|
||
.B OMITs
|
||
are not counted. (Strict date subtraction is performed.)
|
||
.TP
|
||
.B %y
|
||
is replaced with "\fIyear\fR", the year of the trigger date.
|
||
.TP
|
||
.B %z
|
||
is replaced with "\fIyy\fR", the last two digits of the year.
|
||
.TP
|
||
.B %(\fIany_text\fR\fB)
|
||
is replaced with the lookup of \fIany_text\fR in the translation table.
|
||
It is the equivalent of [_("any_text")] but is more convenient to type.
|
||
.TP
|
||
.B %<\fIany_text\fR\fB>
|
||
is replaced with the INFO value associated with the header \fIany_text\fR
|
||
or the empty string if no such INFO value exists. It is the
|
||
equivalent of [triginfo("any_text")] but is more convenient to type.
|
||
.TP
|
||
.B %_
|
||
(percent-underscore) is replaced with a newline. You can use this to
|
||
achieve multi-line reminders. Note that calendar back-ends vary in
|
||
how they handle multi-line reminders:
|
||
.RS
|
||
.TP
|
||
.B o
|
||
Running \fBremind -c\fR preserves newlines in the terminal calendar output.
|
||
.TP
|
||
.B o
|
||
\fBrem2pdf\fR preserves newlines if \fBremind\fR is invoked with the \fB\-pp\fR
|
||
or \fB\-ppp\fR option.
|
||
.TP
|
||
.B o
|
||
\fBrem2html\fR preserves newlines if \fBremind\fR is invoked with the
|
||
\fB\-pp\fR option.
|
||
.TP
|
||
.B o
|
||
\fBtkremind\fR preserves newlines.\fR
|
||
.TP
|
||
.B o
|
||
\fBrem2ps\fR converts newlines to spaces. But \fBrem2ps\fR is deprecated;
|
||
use \fBrem2pdf\fR instead.
|
||
.TP
|
||
.B o
|
||
The "simple calendar" formats (i.e., \fBremind\fR's \fB\-s\fR, \fB\-n\fR and
|
||
\fB\-p\fR options) convert newlines to spaces.
|
||
.PP
|
||
All calendar back-ends collapse multiple spaces to a single space and
|
||
multiple newlines to a single newline.
|
||
.RE
|
||
.TP
|
||
.B %1
|
||
is replaced with "now", "\fIm\fR minutes from now", "\fIm\fR minutes ago",
|
||
"\fIh\fR hours from now", "\fIh\fR hours ago", "\fIh\fR hours and \fIm\fR
|
||
minutes from now" or "\fIh\fR hours and \fIm\fR minutes ago", as appropriate
|
||
for a timed reminder. Note that unless you specify the \fB\-a\fR option,
|
||
timed reminders will be triggered like normal reminders, and thus a timed
|
||
reminder that occurred earlier in the day may be triggered. This
|
||
causes the need for the "...ago" forms.
|
||
.TP
|
||
.B %2
|
||
is replaced with "at \fIhh\fR:\fImm\fRam" or "..pm" depending on the
|
||
.B AT
|
||
time of the reminder.
|
||
.TP
|
||
.B %3
|
||
is replaced with "at \fIhh\fR:\fImm\fR" in 24-hour format.
|
||
.TP
|
||
.B %4
|
||
is replaced with "\fImm\fR" where \fImm\fR is the number of minutes between
|
||
"now" and the time specified by \fBAT\fR. If the \fBAT\fR time is
|
||
earlier than the current time, then the result is negative.
|
||
.TP
|
||
.B %5
|
||
is replaced with "\fIma\fR" where \fIma\fR is the absolute value of the number
|
||
produced by \fB%4\fR.
|
||
.TP
|
||
.B %6
|
||
is replaced with "ago" or "from now", depending on the relationship between
|
||
the \fBAT\fR time and the current time.
|
||
.TP
|
||
.B %7
|
||
is replaced with the number of hours between the \fBAT\fR time and the
|
||
current time. It is always non-negative.
|
||
.TP
|
||
.B %8
|
||
is replaced with the number of minutes between the \fBAT\fR time and
|
||
the current time, after the hours (\fB%7\fR) have been subtracted out.
|
||
This is a number ranging from 0 to 59.
|
||
.TP
|
||
.B %9
|
||
is replaced with "s" if the value produced by \fB%8\fR is not 1.
|
||
.TP
|
||
.B %0
|
||
is replaced with "s" if the value produced by \fB%7\fR is not 1.
|
||
.TP
|
||
.B %!
|
||
is replaced with "is" if the current date and time is before the
|
||
trigger date and the \fBAT\fR time, or "was" if it is after. The \fB%!\fR
|
||
sequence may be used in a non-timed reminder, in which case only dates
|
||
are compared.
|
||
.TP
|
||
.B %?
|
||
is replaced with "are" if the current date and time is before the
|
||
trigger date and the \fBAT\fR time, or "were" if it is after. The \fB%?\fR
|
||
sequence may be used in a non-timed reminder, in which case only dates
|
||
are compared.
|
||
.TP
|
||
.B %@
|
||
is similar to \fB%2\fR but displays the current time.
|
||
.TP
|
||
.B %#
|
||
is similar to \fB%3\fR but displays the current time.
|
||
.TP
|
||
.B %:
|
||
is replaced with " (done)" for a TODO reminder whose trigger date
|
||
is on or after its COMPLETE-THROUGH date. It is replaced with the empty
|
||
string in any other situation. Note that because \fBRemind\fR does not
|
||
display completed TODO reminders in Agenda Mode, this escape sequence
|
||
is really only useful in Calendar Mode.
|
||
.TP
|
||
.B
|
||
%"
|
||
.\" "
|
||
(percent-doublequote) is removed. This sequence is not
|
||
used by the substitution filter,
|
||
but is used to tell \fBRemind\fR which text to include in a calendar
|
||
entry when the \fB\-c\fR, \fB\-s\fR or \fB\-p\fR option is chosen.
|
||
See "CALENDAR MODE"
|
||
.PP
|
||
Notes:
|
||
.TP
|
||
o
|
||
.B Remind
|
||
normally prints a blank line after each reminder; if the last character
|
||
of the body is "%", the blank line will not be printed. You can globally
|
||
suppress the extra blank lines by setting \fB$AddBlankLines\fR to 0.
|
||
.TP
|
||
o
|
||
Substitutions a, b, c, e, f, g, h, i, j, k, l, u and v all are replaced
|
||
with "today" if the current date equals the trigger date, or "tomorrow"
|
||
if the trigger date is one day after the current date. Thus, they are
|
||
.B not
|
||
the same as substitutions built up from the simpler %w, %y, etc.
|
||
sequences.
|
||
.TP
|
||
o
|
||
The a, c, e, f, g, h, i, j, k, l, u, v, 2, and 3 substitutions may
|
||
be preceded by an asterisk (for example, \fB%*c\fR) which causes the word
|
||
"at" or "on" that would normally be included in the output to be
|
||
omitted.
|
||
.TP
|
||
o
|
||
The ! and ? substitutions may be preceded by an asterisk (\fB%*!\fR or \fB%*?\fR),
|
||
in which case the comparison is made between the trigger date and
|
||
realtoday() instead of today().
|
||
.TP
|
||
o
|
||
Any of the substitutions dealing with time (0 through 9) produce
|
||
undefined results if used in a reminder that does not have an \fBAT\fR
|
||
keyword. Also, if a reminder has a \fIdelta\fR and may be triggered
|
||
on several days, the time substitutions ignore the date. Thus, the
|
||
\fB%1\fR substitution may report that a meeting is in 15 minutes, for
|
||
example, even though it may only be in 2 days time, because a
|
||
\fIdelta\fR has triggered the reminder. It is recommended that you
|
||
use the time substitutions only in timed reminders with no \fIdelta\fR
|
||
that are designed to be queued for timed activation.
|
||
.TP
|
||
o
|
||
Capital letters can be used in the substitution sequence, in which case
|
||
the first character of the substituted string is capitalized (if it is
|
||
normally a lower-case letter.)
|
||
.TP
|
||
o
|
||
All other characters following a "%" sign are simply copied. In particular,
|
||
to get a "%" sign out, use "%%" in the body. To start the body of a reminder
|
||
with a space, use "% ", since
|
||
.B Remind
|
||
normally scans for the first non-space character after a
|
||
.B MSG,
|
||
.B CAL
|
||
or
|
||
.B RUN
|
||
token.
|
||
.PP
|
||
.SH EVENTS AND TODOS
|
||
.PP
|
||
The \fBREM\fR command is normally used to create an \fIEVENT\fR. This
|
||
is something that happens at a certain time, possibly recurring, and
|
||
happens no matter what action you take. Events include things like
|
||
birthdays, holidays, meetings, etc... pretty much everything that occurs
|
||
on a particular schedule. Once the date of an event has passed,
|
||
\fBRemind\fR will no longer remind you about the event.
|
||
.PP
|
||
A \fITODO\fR is different; it is a task that you have to complete by a
|
||
specific date or date and time. If you don't explicitly mark a TODO
|
||
as done, \fBRemind\fR will keep reminding you about it \fIeven past
|
||
the due date.\fR.
|
||
.PP
|
||
To mark a \fBREM\fR as a TODO, simply include the TODO keyword. For example:
|
||
.PP
|
||
.nf
|
||
REM TODO 15 August 2025 ++5 MSG Buy cat food %b.
|
||
.fi
|
||
.PP
|
||
In Agenda Mode, \fBRemind\fR will start warning you on 10 Aug 2025 that
|
||
you have to but cat food in 5 days' time, 4 days' time, etc...
|
||
.PP
|
||
However, on 16 Aug 2025, \fBRemind\fR will say "Buy cat food yesterday."
|
||
and it will keep reminding you of your need to buy cat food until the end
|
||
of time, or until you mark the TODO as done.
|
||
.PP
|
||
.SH MARKING TODOS AS DONE
|
||
.PP
|
||
There are two ways to mark a TODO as done. If the TODO is not recurring,
|
||
the simplest way is simply to remove the TODO designator from the REM
|
||
command (or indeed, to completely delete it.) The former keeps the
|
||
reminder on the calendar while the latter completely removes it.
|
||
.PP
|
||
If a TODO is recurring, use the \fBCOMPLETE-THROUGH\fR clause to mark
|
||
which recurrences have been completed. For example:
|
||
.PP
|
||
.nf
|
||
REM TODO 30 April ++15 COMPLETE-THROUGH 2025-04-30 MSG File taxes
|
||
.fi
|
||
.PP
|
||
Canadian income taxes must be filed every 30 April. The above command
|
||
will remind you to pay taxes in 2026. If you don't update the
|
||
COMPLETE-THROUGH date, then after 30 April 2026, \fBRemind\fR will
|
||
keep reminding you until the end of time that your taxes were due on 30
|
||
April 2026. To indicate that you've paid them, simply update the
|
||
COMPLETE-THROUGH date to 2026-04-30 and then \fBRemind\fR will start
|
||
reminding you of your 2027 taxes (starting 15 days before the due
|
||
date.)
|
||
.PP
|
||
It is an error to specify COMPLETE-THROUGH without also specifying TODO.
|
||
The keyword COMPLETED-THROUGH may be used as a synonym for COMPLETE-THROUGH.
|
||
.PP
|
||
.SH LIMITING REMINDERS ABOUT OVERDUE TODOS
|
||
.PP
|
||
Although \fBRemind\fR is happy to keep reminding you about overdue
|
||
TODOs for hundreds of years, for some things this may be pointless.
|
||
If you want \fBRemind\fR to \fIstop\fR nagging you about an overdue
|
||
TODO after a certain number of days, use the MAX-OVERDUE \fIn\fR clause.
|
||
In this case, \fBRemind\fR stops reminding you of a TODO that is overdue
|
||
by more than \fIn\fR days. Here is an example.
|
||
.PP
|
||
.nf
|
||
REM TODO 2025-08-13 ++5 MAX-OVERDUE 5 MSG Task: %b.
|
||
.fi
|
||
.PP
|
||
\fBRemind\fR \fIstarts\fR reminding you of the task on 2025-08-08,
|
||
because of the ++5 back value. It keeps reminding you of the task
|
||
after the due date. However, the last time it will remind you
|
||
will be on 2025-08-18, because of the MAX-OVERDUE clause. Starting
|
||
on 2025-08-19, \fBRemind\fR will no longer remind you of the task
|
||
since it's probably pointless---it has passed the MAX-OVERDUE period.
|
||
.PP
|
||
.SH MORE DETAILS ABOUT TODOS
|
||
.PP
|
||
TODOs are treated specially only in Agenda Mode. In Calendar Mode,
|
||
they appear in the calendar exactly as a normal event would.
|
||
.PP
|
||
TODOs are implemented internally by using the COMPLETE-THROUGH date
|
||
plus one day as the starting point for \fBRemind\fR's date-scanning
|
||
algorithm. If you have a recurring TODO without a COMPLETE-THROUGH
|
||
clause, then \fBRemind\fR starts scanning from the beginning of time,
|
||
which we all know is 1 January 1990. Consider this command:
|
||
.PP
|
||
.nf
|
||
REM TODO Wed +7 MSG Take out the trash %a (%b)
|
||
.fi
|
||
.PP
|
||
Running that command in Agenda Mode on 2025-08-13 yields the following output:
|
||
.PP
|
||
.nf
|
||
Take out the trash on Wednesday, 3 January, 1990 (13006 days ago)
|
||
.fi
|
||
.PP
|
||
\fBRemind\fR is very persistent about reminding you of tasks! If you take
|
||
out the trash and mark it done:
|
||
.PP
|
||
.nf
|
||
REM TODO Wed +7 COMPLETE-THROUGH 2025-08-13 MSG Take out the trash %a (%b)
|
||
.fi
|
||
.PP
|
||
then you get this:
|
||
.PP
|
||
.nf
|
||
Take out the trash on Wednesday, 20 August, 2025 (in 7 days' time)
|
||
.fi
|
||
.PP
|
||
You can use \fBFROM\fR and \fBUNTIL\fR to limit the recurrence interval of
|
||
tasks just as you can with events. For example, if you are house-sitting
|
||
for the month of August and need to water plants every Wednesday:
|
||
.PP
|
||
.nf
|
||
REM TODO Wed +7 FROM 2025-08-06 UNTIL 2025-08-27 MSG Plants %b.
|
||
.fi
|
||
.PP
|
||
Running that command on 13 Aug yields: "Plants 7 days ago." because you
|
||
have not told \fBRemind\fR that you completed the first watering. If you finish
|
||
your duties and add a COMPLETE-THROUGH date of 2025-08-27, then \fBRemind\fR
|
||
never reminds you of that task in the future.
|
||
.PP
|
||
In Purge Mode, \fBRemind\fR will not purge TODOs unless they have been marked
|
||
as complete. In the case of a recurring TODO, \fBRemind\fR will not purge
|
||
it until the last occurrence is marked as complete.
|
||
.PP
|
||
.SH THE OMIT COMMAND
|
||
.PP
|
||
In addition to being a keyword in the \fBREM\fR command,
|
||
\fBOMIT\fR is a command in its own right. Its syntax is:
|
||
.PP
|
||
.RS
|
||
\fBOMIT\fR \fIweekday\fR [\fIweekday\fR...]
|
||
.PP
|
||
or:
|
||
.PP
|
||
\fBOMIT\fR [\fIday\fR] \fImonth\fR [\fIyear\fR]
|
||
.PP
|
||
or:
|
||
.PP
|
||
\fBOMIT\fR [\fIday1\fR] \fImonth1\fR [\fIyear1\fR] \fBTHROUGH\fR [\fIday2\fR] \fImonth2\fR [\fIyear2\fR]
|
||
.RE
|
||
.PP
|
||
The \fBOMIT\fR command is used to "globally" omit certain days
|
||
(usually holidays). These globally-omitted days are skipped by the
|
||
"\-" and "+" forms of \fIback\fR and \fIdelta\fR, but not by the
|
||
"\-\-" and "++" forms. Some examples:
|
||
.PP
|
||
.nf
|
||
OMIT Saturday Sunday
|
||
OMIT 1 Jan
|
||
OMIT 7 Sep 1992
|
||
OMIT 15 Jan THROUGH 14 Feb
|
||
OMIT May # Equivalent to OMIT May 1 THROUGH May 31
|
||
OMIT 25 Dec THROUGH 4 Jan
|
||
OMIT 2023-05-03 THROUGH 2023-05-12
|
||
OMIT Jun THROUGH July # Equivalent to OMIT Jun 1 THROUGH July 31
|
||
.fi
|
||
.PP
|
||
The first example omits every Saturday and Sunday. This is useful for
|
||
reminders that shouldn't trigger on weekends.
|
||
.PP
|
||
The second example specifies a holiday that occurs on the same date each
|
||
year - New Year's Day.
|
||
.PP
|
||
The third example specifies a holiday that
|
||
changes each year - Labour Day. For these types of holidays, you
|
||
must create an \fBOMIT\fR command for each year. (Later, in the
|
||
description of expressions and some of the more advanced features of
|
||
\fBRemind\fR, you will see how to automate this for some cases.)
|
||
.PP
|
||
As with the REM command, you can use shorthand specifiers for dates;
|
||
the following are equivalent:
|
||
.PP
|
||
.nf
|
||
OMIT 7 Sep 1992
|
||
OMIT 1992-09-07
|
||
.fi
|
||
.PP
|
||
For convenience, you can use a \fIdelta\fR and \fBMSG\fR or \fBRUN\fR
|
||
keyword in the \fBOMIT\fR command. The following sequences are
|
||
equivalent:
|
||
.PP
|
||
.nf
|
||
OMIT 1 Jan
|
||
REM 1 Jan +4 MSG New year's day is %b!
|
||
|
||
and
|
||
|
||
OMIT 1 Jan +4 MSG New year's day is %b!
|
||
.fi
|
||
.PP
|
||
The \fBTHROUGH\fR keyword lets you conveniently OMIT a range of days.
|
||
For example, the following sequences are equivalent:
|
||
.PP
|
||
.nf
|
||
OMIT 3 Jan 2011
|
||
OMIT 4 Jan 2011
|
||
OMIT 5 Jan 2011
|
||
|
||
and
|
||
|
||
OMIT 3 Jan 2011 THROUGH 5 Jan 2011
|
||
.fi
|
||
.PP
|
||
Note that \fBRemind\fR has a compiled-in limit to the number of full
|
||
OMITs. If you omit a range of \fIN\fR fully-specified (i.e., year
|
||
included) days, then \fIN\fR full OMITs are used up. Trying to omit a
|
||
very large range may result in the error "Too many full OMITs"
|
||
.PP
|
||
You can make a THROUGH \fBOMIT\fR do double-duty as a \fBREM\fR command as
|
||
long as both dates are fully specified
|
||
.PP
|
||
.nf
|
||
OMIT 6 Sep 2010 THROUGH 10 Sep 2010 MSG Vacation
|
||
.fi
|
||
.PP
|
||
If you use a THROUGH clause, then either the year must be supplied before
|
||
and after the THROUGH, or it must be missing before and after the THROUGH.
|
||
The following are legal:
|
||
.PP
|
||
.nf
|
||
OMIT 25 Dec THROUGH 6 Jan
|
||
OMIT 25 Dec 2024 THROUGH 6 Jan 2025
|
||
.fi
|
||
.PP
|
||
But the following are not:
|
||
.PP
|
||
.nf
|
||
OMIT 25 Dec THROUGH 6 Jan 2025
|
||
OMIT 25 Dec 2024 THROUGH 6 Jan
|
||
.nf
|
||
.PP
|
||
You can debug your global OMITs with the following command:
|
||
.PP
|
||
.nf
|
||
OMIT DUMP
|
||
.fi
|
||
.PP
|
||
The OMIT DUMP command prints the current global omits to standard output.
|
||
.PP
|
||
.B THE BEFORE, AFTER AND SKIP KEYWORDS
|
||
.PP
|
||
Normally, days that are omitted, whether by a global \fBOMIT\fR
|
||
command or the local \fBOMIT\fR or \fBOMITFUNC\fR keywords in a
|
||
\fBREM\fR statement, only affect the counting of the \-\fIback\fR or
|
||
the +\fIdelta\fR. For example, suppose you have a meeting every
|
||
Wednesday. Suppose, too, that you have indicated 11 Nov as a holiday:
|
||
.PP
|
||
.nf
|
||
OMIT 11 Nov +4 MSG Remembrance Day
|
||
REM Wed +1 MSG Code meeting %b.
|
||
.fi
|
||
.PP
|
||
The above sequence will issue a reminder about a meeting for 11 November 1992,
|
||
which is a Wednesday. This is probably incorrect. There are three
|
||
options:
|
||
.TP
|
||
.B BEFORE
|
||
This keyword moves the reminder to before any omitted days. Thus, in
|
||
the above example, use of \fBBEFORE\fR would cause the meeting reminder
|
||
to be triggered on Tuesday, 10 November 1992.
|
||
.TP
|
||
.B AFTER
|
||
This keyword moves the reminder to after any omitted days. In the above
|
||
example, the meeting reminder would be triggered on Thursday, 12 November
|
||
1992.
|
||
.TP
|
||
.B SKIP
|
||
This keyword causes the reminder to be skipped completely on any omitted
|
||
days. Thus, in the above example, the reminder would not be triggered
|
||
on 11 November 1992. However, it would be triggered as usual on the following
|
||
Wednesday, 18 November 1992.
|
||
.PP
|
||
The \fBBEFORE\fR and \fBAFTER\fR keywords move the trigger date of a
|
||
reminder to before or after a block of omitted days, respectively.
|
||
Suppose you normally run a backup on the first day of the month. However,
|
||
if the first day of the month is a weekend or holiday, you run the backup
|
||
on the first working day following the weekend or holiday. You could use:
|
||
.PP
|
||
.nf
|
||
REM 1 OMIT Sat Sun AFTER RUN do_backup
|
||
.fi
|
||
.PP
|
||
Let's examine how the trigger date is computed. The \fB1\fR specifies
|
||
the first day of the month. The local \fBOMIT\fR keyword causes the
|
||
\fBAFTER\fR keyword to move the reminder forward past weekends.
|
||
Finally, the \fBAFTER\fR keyword will keep moving the reminder forward
|
||
until it has passed any holidays specified with global \fBOMIT\fR
|
||
commands.
|
||
.PP
|
||
.SH TIMEZONE SUPPORT
|
||
.PP
|
||
The \fBREM\fR command supports an optional \fBTZ\fR keyword, which should
|
||
be followed by the \fIcase-sensitive\fR time zone name in which the
|
||
command is to be interpreted. Note that if you use the \fBTZ\fR keyword,
|
||
then you \fImust also\fR use an \fBAT\fR clause. Here are some examples:
|
||
.PP
|
||
.nf
|
||
REM Wednesday AT 14:00 TZ America/Toronto MSG 2PM Eastern (%2).
|
||
REM Wednesday AT 23:59 TZ America/Los_Angeles SATISFY [$Td == 13] MSG Foo %b %2.
|
||
.fi
|
||
.PP
|
||
Within a \fBSATISFY\fR clause and an \fBOMITFUNC\fR function, all
|
||
trigger functions and the trigger date are interpreted \fIin the time
|
||
zone specified in the \fBREM\fI command\fR. Outside the \fBREM\fR
|
||
command, however, trigger functions are adjusted to the local time
|
||
zone. If the local time zone is UTC and we feed \fBRemind\fR the
|
||
following file on 2025-09-04 UTC:
|
||
.PP
|
||
.nf
|
||
SET $AddBlankLines 0
|
||
BANNER %
|
||
REM Wednesday AT 14:00 TZ America/Toronto MSG 2PM Eastern (%2).
|
||
set a $T
|
||
set b $Tt
|
||
REM MSG a = [a], b = [b]
|
||
REM Wednesday AT 23:59 TZ America/Los_Angeles SATISFY [$Td == 13] MSG Foo %b %2.
|
||
set c $T
|
||
set d $Tt
|
||
REM MSG c = [c], d = [d]
|
||
.fi
|
||
.PP
|
||
Then the output is as follows:
|
||
.PP
|
||
.nf
|
||
a = 2025-09-10, b = 18:00
|
||
c = 2026-05-14, d = 06:59
|
||
.fi
|
||
.PP
|
||
That is because the trigger date of the first (Wednesday, 2025-09-10
|
||
at 14:00 Eastern time) is 2025-09-10 at 18:00 UTC. In the second case,
|
||
Wednesday, 13 May 2026 is the SATISFied trigger date, which is
|
||
adjusted to Thursday, 14 May 2026 at 06:59 UTC because of the
|
||
time zone adjustment.
|
||
.PP
|
||
If you use an invalid time zone name after the \fBTZ\fR keyword,
|
||
results are undefined. As mentioned previously, time zone names
|
||
\fIare\fR case-sensitive; America/Toronto is valid, but
|
||
america/toronto is not.
|
||
.PP
|
||
If you are on a system that stores time zone data in
|
||
/usr/share/zoneinfo, then \fBRemind\fR will attempt to validate the
|
||
time zone name and will warn you if it appears to be invalid. If you
|
||
want to specify a time zone that lacks a file under
|
||
/usr/share/zoneinfo anyway, and want to suppress the warning, prefix
|
||
the time zone name with "!". For example:
|
||
.PP
|
||
.nf
|
||
REM Thursday AT 14:45 TZ !EST+5EDT,M3.2.0/2,M11.1.0/2 MSG Old TZ format
|
||
.fi
|
||
.PP
|
||
In a reminder with the \fBTZ\fR keyword, OMIT dates are evaluated in
|
||
the specified time zone. Here's an example: Suppose the local time zone
|
||
is America/Toronto and you have this script:
|
||
.PP
|
||
.nf
|
||
# A Friday
|
||
OMIT 2025-09-05
|
||
|
||
# A Saturday
|
||
OMIT 2025-09-13
|
||
|
||
REM Saturday AT 01:00 TZ Europe/Amsterdam SKIP MSG Early Sat AM
|
||
.fi
|
||
.PP
|
||
On 2025-09-05 in the America/Toronto time zone, the reminder \fIwill\fR
|
||
trigger. Even though 2025-09-05 has been OMITted, the SKIP keyword
|
||
evaluates the date in the Europe/Amsterdam time zone, and 2025-09-06
|
||
(the trigger date) is \fInot\fR omitted.
|
||
.PP
|
||
Conversely, on 2025-09-12 in the America/Toronto time zone, the
|
||
reminder will \fInot\fR trigger. Even though 2025-09-12 is not OMITted,
|
||
2025-09-13 is, and that is the trigger date in the Europe/Amsterdam
|
||
time zone.
|
||
.PP
|
||
.SH THE DO, INCLUDE AND SYSINCLUDE COMMANDS
|
||
.PP
|
||
\fBRemind\fR allows you to include other files in your reminder script,
|
||
similar to the C preprocessor #include directive. For example, you
|
||
might organize different reminders into different files like this:
|
||
.PP
|
||
.nf
|
||
INCLUDE holidays.rem
|
||
INCLUDE birthdays.rem
|
||
INCLUDE "quote files with spaces.rem"
|
||
.fi
|
||
.PP
|
||
\fBINCLUDE\fR files can be nested up to a depth of 8. As shown above, if a
|
||
filename has spaces in it (not recommended!) you can use double-quotes
|
||
around the filename.
|
||
.PP
|
||
If you specify a filename of "-" in the \fBINCLUDE\fR command, \fBRemind\fR
|
||
will begin reading from standard input.
|
||
.PP
|
||
If you specify a \fIdirectory\fR as the argument to \fBINCLUDE\fR,
|
||
then \fBRemind\fR will process all files (but not subdirectories!) in
|
||
that directory that match the shell pattern "*.rem". The files are
|
||
processed in sorted order; the sort order matches that used by the
|
||
shell when it expands "*.rem".
|
||
.PP
|
||
Note that the file specified by an \fBINCLUDE\fR command is interpreted
|
||
relative to the \fIcurrent working directory of the \fBRemind\fR process\fR.
|
||
If you want to include a file relative to the directory containing the
|
||
currently-processing file, use \fBDO\fR instead. For example,
|
||
if the current file is \fB/home/user/.reminders/foo.rem\fR and Remind's
|
||
working directory is \fB/home/user\fR, then:
|
||
.PP
|
||
.nf
|
||
# Read /home/user/.reminders/bar.rem
|
||
DO bar.rem
|
||
|
||
# Read /usr/share/bar.rem - absolute path
|
||
DO /usr/share/bar.rem
|
||
|
||
# Read /home/user/bar.rem
|
||
INCLUDE bar.rem
|
||
|
||
# Read /usr/share/bar.rem - absolute path
|
||
INCLUDE /usr/share/bar.rem
|
||
.fi
|
||
.PP
|
||
Arguably, the \fBINCLUDE\fR command should have worked the way \fBDO\fR
|
||
does right from the start, but changing it would have broken
|
||
backward-compatibility, hence the introduction of \fBDO\fR.
|
||
.PP
|
||
Note that if the currently-processing reminders file was specified as
|
||
a symbolic link to a file that is not in the same directory as the
|
||
symbolic link itself, \fBDO\fR will fail. \fBRemind\fR does \fInot\fR
|
||
resolve the real path of symbolic links, so you should avoid using
|
||
symbolic links to files.
|
||
.PP
|
||
The \fBSYSINCLUDE\fR command is similar to \fBDO\fR, but it looks for
|
||
relative pathnames under the system directory containing standard reminder
|
||
scripts. For this installation of \fBRemind\fR, the system directory is
|
||
"@prefix@/share/remind".
|
||
.PP
|
||
.SH THE RETURN COMMAND
|
||
.PP
|
||
The \fBRETURN\fR command causes \fBRemind\fR to ignore the remaining
|
||
contents of the file currently being processed. It can be used as a
|
||
quick way to "exit" from an included file (though it also works at
|
||
the top-level.)
|
||
.PP
|
||
Here is an example of how \fBRETURN\fR might be used:
|
||
.PP
|
||
.nf
|
||
IF already_done
|
||
RETURN
|
||
ENDIF
|
||
set already_done 1
|
||
preserve already_done
|
||
# Do expensive processing here
|
||
.fi
|
||
.PP
|
||
.SH THE RUN COMMAND
|
||
.PP
|
||
If you include other files in your reminder script, you may not always
|
||
entirely trust the contents of the other files. For example, they
|
||
may contain \fBRUN\fR-type reminders that could be used to access your
|
||
files or perform undesired actions. The \fBRUN\fR command can restrict
|
||
this: If you include the command \fBRUN OFF\fR in your top-level reminder
|
||
script, any reminder or expression that would normally execute a system
|
||
command is disabled. \fBRUN ON\fR will re-enable the execution of
|
||
system commands. Note that the \fBRUN ON\fR command can \fIonly\fR be used
|
||
in your top-level reminder script; it will \fInot\fR work in any files
|
||
accessed by the \fBINCLUDE\fR command. This is to protect you from someone
|
||
placing a \fBRUN ON\fR command in an included file. However, the
|
||
\fBRUN OFF\fR command can be used at top level or in an included file.
|
||
.PP
|
||
If you run \fBRemind\fR with the \fB\-r\fR command-line option,
|
||
\fBRUN\fR-type reminders and the \fBshell()\fR function will be disabled,
|
||
regardless of any \fBRUN\fR commands in the reminder script. However,
|
||
any command supplied with the \fB\-k\fR option will still be executed.
|
||
.PP
|
||
In addition, \fBRemind\fR contains a few other security
|
||
features. It will not read a file that is group- or world-writable.
|
||
It will not run set-uid. If it reads a file you don't own, it will
|
||
disable RUN and the shell() function. And if it is run as \fIroot\fR,
|
||
it will only read files owned by \fIroot\fR.
|
||
.PP
|
||
Note that if \fBRemind\fR reads standard input, it does \fInot\fR
|
||
attempt to check the ownership of standard input, even if it is
|
||
coming from a file, and hence does \fInot\fR disable RUN and shell()
|
||
in this situation.
|
||
|
||
.PP
|
||
.SH THE EXPR COMMAND
|
||
.PP
|
||
\fBRemind\fR lets you completely disable expression evaluation. This
|
||
could be useful if you are running \fBRemind\fR on a somewhat-untrustworthy
|
||
file that is not expected to contain expressions. To disable
|
||
expression evaluation, use:
|
||
.PP
|
||
.nf
|
||
EXPR OFF
|
||
.fi
|
||
.PP
|
||
If \fBRemind\fR encounters an expression while EXPR OFF is in effect, it
|
||
returns an error
|
||
.PP
|
||
To re-enable expression evaluation, use:
|
||
.PP
|
||
.nf
|
||
EXPR ON
|
||
.fi
|
||
.PP
|
||
As with \fBRUN ON\fB, \fBEXPR ON\fR can be used only in the top-level
|
||
script, not in an included file.
|
||
.PP
|
||
.SH THE INCLUDECMD COMMAND
|
||
.PP
|
||
\fBRemind\fR allows you to execute a shell command and evaluate the
|
||
output of that command as if it were an included file. For example,
|
||
you could have scripts that extract reminders out of a database and print
|
||
them on stdout as REM commands. Here is an example:
|
||
.PP
|
||
.nf
|
||
INCLUDECMD extract_reminders_for dfs
|
||
.fi
|
||
.PP
|
||
We assume that the command "extract_reminders_for" extracts reminders out
|
||
of a central database for the named user. Another use-case of INCLUDECMD
|
||
is if you have your reminders stored in a file in some non-Remind format;
|
||
you can write a command that transforms them to \fBRemind\fR format and then
|
||
\fBRemind\fR can "include" the file with an appropriate INCLUDECMD command.
|
||
.PP
|
||
Note that if RUN is disabled, then INCLUDECMD will fail with the error
|
||
message "RUN disabled"
|
||
.PP
|
||
\fBRemind\fR arranges so that when the command specified by INCLUDECMD is
|
||
executed, its standard input is opened to /dev/null.
|
||
.PP
|
||
INCLUDECMD passes the rest of the line to \fBpopen\fR(3), meaning that
|
||
the command is executed by the shell. As such, shell meta-characters
|
||
may need escaping or arguments quoting, depending on what you're trying
|
||
to do. \fBRemind\fR itself does not perform any modification of the command
|
||
line (apart from the normal [expr] expression-pasting mechanism).
|
||
.PP
|
||
If the command passed to INCLUDECMD begins with an exclamation mark "!",
|
||
then \fBRemind\fR disables \fBRUN\fR for the output of the command. If you are
|
||
running a command whose output you don't quite trust, you should
|
||
prefix it with "!" so that any RUN commands it emits fail.
|
||
.PP
|
||
An \fBINCLUDECMD\fR command counts towards the INCLUDE nesting depth.
|
||
For any given \fBRemind\fR run, a given INCLUDECMD command is only executed
|
||
once and the results are cached. For example, if you generate a
|
||
calendar, each unique INCLUDECMD command is run just once, not once
|
||
for each day of the produced calendar. "Uniqueness" is determined by
|
||
looking at the command that will be passed to the shell, so if (for example)
|
||
your INCLUDECMD uses expression-pasting that results in differences depending
|
||
on the value of \fBtoday()\fR, then each \fIunique\fR version of the
|
||
command will be executed once.
|
||
.PP
|
||
If a given reminder file contains more than one identical
|
||
\fBINCLUDECMD\fR, only the first one will actually be executed. All
|
||
subsequent identical ones will use the cached output from the first one.
|
||
.PP
|
||
|
||
.SH THE BANNER COMMAND
|
||
.PP
|
||
When \fBRemind\fR first issues a reminder, it prints a message like this:
|
||
.PP
|
||
.nf
|
||
Reminders for Friday, 30th October, 1992 (today):
|
||
.fi
|
||
.PP
|
||
(The banner is not printed if any of the calendar-producing options
|
||
is used, or if the \fB\-k\fR option is used.)
|
||
.PP
|
||
The \fBBANNER\fR command lets you change the format. It should appear
|
||
before any \fBREM\fR commands. The format is:
|
||
.PP
|
||
.RS
|
||
\fBBANNER\fR \fIformat\fR
|
||
.RE
|
||
.PP
|
||
The \fIformat\fR is similar to the \fIbody\fR of a \fBREM\fR command. It
|
||
is passed through the substitution filter, with an implicit trigger of
|
||
the current system date. Thus, the default banner is equivalent to:
|
||
.PP
|
||
.nf
|
||
BANNER Reminders for %w, %d%s %m, %y%o:
|
||
.fi
|
||
.PP
|
||
You can disable the banner completely with BANNER %. Or you can create
|
||
a custom banner:
|
||
.PP
|
||
.nf
|
||
BANNER Hi - here are your reminders for %y-%t-%r:
|
||
.fi
|
||
.SH CONTROLLING THE OMIT CONTEXT
|
||
.PP
|
||
Sometimes, it is necessary to temporarily change the global \fBOMITs\fR
|
||
that are in force for a few reminders. Three commands allow you to do
|
||
this:
|
||
.TP
|
||
.B PUSH-OMIT-CONTEXT
|
||
This command saves the current global \fBOMITs\fR on an internal stack.
|
||
.TP
|
||
.B CLEAR-OMIT-CONTEXT
|
||
This command clears all of the global \fBOMITs\fR, starting you off with
|
||
a "clean slate."
|
||
.TP
|
||
.B POP-OMIT-CONTEXT
|
||
This command restores the global \fBOMITs\fR that were saved by the most
|
||
recent \fBPUSH-OMIT-CONTEXT\fR.
|
||
.PP
|
||
For example, suppose you have a block of reminders that require a clear
|
||
\fBOMIT\fR context, and that they also introduce unwanted global \fBOMITs\fR
|
||
that could interfere with later reminders. You could use the following
|
||
fragment:
|
||
.PP
|
||
.nf
|
||
PUSH-OMIT-CONTEXT # Save the current context
|
||
CLEAR-OMIT-CONTEXT # Clean the slate
|
||
# Block of reminders goes here
|
||
POP-OMIT-CONTEXT # Restore the saved omit context
|
||
.fi
|
||
.SH EXPRESSIONS
|
||
.PP
|
||
In certain contexts, to be described later, \fBRemind\fR will accept
|
||
expressions for evaluation. \fBRemind\fR expressions resemble C
|
||
expressions, but operate on different types of objects.
|
||
.PP
|
||
.B DATA TYPES
|
||
.PP
|
||
\fBRemind\fR expressions operate on five types of objects:
|
||
.TP
|
||
.B INT
|
||
The \fBINT\fR data type consists of the integers representable in one machine
|
||
word. The \fBINT\fR data type corresponds to the C "int" type.
|
||
.TP
|
||
.B STRING
|
||
The \fBSTRING\fR data type consists of strings of characters. It is
|
||
somewhat comparable to a C character array, but more closely resembles
|
||
the string type in BASIC.
|
||
.RS
|
||
.PP
|
||
\fBRemind\fR normally expects to be running in a UTF-8 environment.
|
||
In this environment, there is a difference between \fIbytes\fR and
|
||
\fIcharacters\fR since in UTF-8, a character may be represented by
|
||
a sequence of more than one byte. For example, in a UTF-8 environment,
|
||
the string "🙂" contains one character but four bytes. And the string
|
||
"één" contains three characters but five bytes.
|
||
.PP
|
||
\fBRemind\fR has a set of functions
|
||
that work on \fIbytes\fR, namely \fBindex\fR, \fBstrlen\fR and \fBsubstr\fR.
|
||
These are not safe to use on multi-byte strings; instead use
|
||
\fBmbindex\fR, \fBmbstrlen\fR and \fBmbsubstr\fR. If you know \fIfor sure\fR
|
||
that a string contains only single-byte characters, then the byte-oriented
|
||
versions may be used and are faster than the multi-byte versions.
|
||
.PP
|
||
Some ancient or embedded systems may lack the C library functions needed
|
||
to deal with multi-byte strings. In that case, the \fBmb\fIxxx\fR functions
|
||
all return an error.
|
||
.RE
|
||
.TP
|
||
.B TIME
|
||
The \fBTIME\fR data type is used for two different purposes: To represent
|
||
a time of day with one-minute precision or to represent a duration
|
||
with one-minute precision. The context of where a \fBTIME\fR is used
|
||
determines whether it is interpreted as a time of day or a duration.
|
||
.RS
|
||
.PP
|
||
In contexts where a \fBTIME\fR represents a time of day, it may range
|
||
from 00:00 to 23:59 and is stored internally as an integer from 0 to
|
||
1439 representing the number of minutes since midnight.
|
||
.PP
|
||
In contexts where a \fBTIME\fR represents a duration, there is no
|
||
upper limit on the hour component (beyond that imposed by the
|
||
restriction that a duration expressed in minutes must fit into the
|
||
signed integer type of your CPU architecture.) Internally, a duration
|
||
is stored as an integer number of minutes.
|
||
.RE
|
||
|
||
.TP
|
||
.B DATE
|
||
The \fBDATE\fR data type consists of dates (later than 1 January 1990.)
|
||
Internally, \fBDATE\fR objects are stored as the number of days since
|
||
1 January 1990.
|
||
.TP
|
||
.B DATETIME
|
||
The \fBDATETIME\fR data type consists of a date and time together.
|
||
Internally, \fBDATETIME\fR objects are stored as the number of minutes
|
||
since midnight, 1 January 1990. You can think of a \fBDATETIME\fR object
|
||
as being the combination of \fBDATE\fR and \fBTIME\fR parts.
|
||
.PP
|
||
.B CONSTANTS
|
||
.PP
|
||
The following examples illustrate constants in \fBRemind\fR expressions:
|
||
.TP
|
||
.B INT constants
|
||
12, 36, \-10, 0, 1209, 0x1F, 0xfe00 (the last two demonstrate the use of hexadecimal constants)
|
||
.TP
|
||
.B STRING constants
|
||
"Hello there", "This is a test", "\\nHello\\tThere", ""
|
||
.PP
|
||
.RS
|
||
Note that the empty string is represented by "". \fBRemind\fR supports
|
||
the escape sequences "\\a", "\\b", "\\f", "\\n", "\\r", "\\t"
|
||
and "\\v" which have the same meanings as their counterparts in C.
|
||
It also supports "\\xAB" where A and B are hexadecimal digits;
|
||
this operates just as in C. The "\\x" must be followed by one or
|
||
two hex digits; the escape sequence "\\x00" is not permitted.
|
||
.PP
|
||
To include a quote in a string, use "\\"". Any other character
|
||
preceded by a backslash is inserted into the string as-is, but the
|
||
backslash itself is removed. To include a backslash in a string,
|
||
use "\\\\".
|
||
.RE
|
||
.TP
|
||
.B TIME constants
|
||
12:33, 0:01, 14:15, 16:42, 12.16, 13.00, 1.11, 4:30PM, 12:20am
|
||
.PP
|
||
.RS
|
||
Note that \fBTIME\fR constants may be written in 24-hour format or in
|
||
common "AM/PM" format. If you use "AM/PM" format, then the hour can
|
||
range from 1 to 12. Either a period or colon can be used to separate
|
||
the minutes from the hours. However, \fBRemind\fR will consistently output
|
||
times in 24-hour format using only one separator character. (The
|
||
output separator character is chosen at compile-time.)
|
||
.PP
|
||
If the \fBTIME\fR is used where \fBRemind\fR expects a time-of-day
|
||
(for example, in an \fBAT\fR clause), then it can be written in
|
||
24-hour format (ranging from 00:00 to 23:59) or 12-hour format
|
||
(ranging from 12:00am to 11:59pm). If the \fBTIME\fR is used where
|
||
\fBRemind\fR expects a duration, it must not have an \fIam\fR or
|
||
\fIpm\fR suffix and the hour can be as large as you want, so long
|
||
as the total number of minutes in the duration fits in a signed integer
|
||
variable.
|
||
.PP
|
||
For convenience, a \fBTIME\fR constant may be surrounded by single
|
||
quotes to match \fBDATE\fR and \fBDATETIME\fR constants, but these
|
||
quotes are optional. That is, 12:56 and '12:56' represent the same
|
||
\fBTIME\fR constant.
|
||
.RE
|
||
.TP
|
||
.B DATE constants
|
||
\fBDATE\fR constants are expressed as 'yyyy/mm/dd' or 'yyyy-mm-dd',
|
||
and the single
|
||
quotes \fImust\fR be supplied. This distinguishes date constants
|
||
from division or subtraction of integers. Examples:
|
||
.PP
|
||
.RS
|
||
\(aq1993/02/22', '1992-12-25', '1999/01/01'
|
||
.PP
|
||
Note that \fBDATE\fR values are \fIprinted\fR
|
||
without the quotes. Although either '-' or '/' is accepted as a date
|
||
separator on input, when dates are printed, only one will be used. The
|
||
choice of whether to use '-' or '/' is made at compile-time.
|
||
Note also that versions
|
||
of \fBRemind\fR prior to 03.00.01 did not support date constants. In those
|
||
versions, you must create dates using the \fBdate()\fR function. Also,
|
||
versions prior to 03.00.02 did not support the '-' date separator.
|
||
.RE
|
||
.TP
|
||
.B DATETIME constants
|
||
\fBDATETIME\fR constants are expressed similarly to \fBDATE\fR
|
||
constants with the addition of an "@HH:MM" part, optionally followed
|
||
by "am" or "pm". For example:
|
||
.PP
|
||
.RS
|
||
\(aq2008-04-05@23:11', '1999/02/03@14:06', '2001-04-07@08:30', '2020-01-01@3:20pm'
|
||
.PP
|
||
\fBDATETIME\fR values are printed without the quotes. Notes about date
|
||
and time separator characters for \fBDATE\fR and \fBTIME\fR constants apply
|
||
also to \fBDATETIME\fR constants.
|
||
.RE
|
||
.PP
|
||
.B ZERO VALUES AND TRUE/FALSE
|
||
.PP
|
||
All types have an associated \fIzero value\fR, which is treated as
|
||
\fIfalse\fR by the IF command, the IIF function, and the logical
|
||
operators. The zero values are:
|
||
.PP
|
||
.RS
|
||
.PP
|
||
\fBINT\fR - 0
|
||
.PP
|
||
\fBDATE\fR - '1990-01-01'
|
||
.PP
|
||
\fBTIME\fR - 00:00
|
||
.PP
|
||
\fBDATETIME\fR - '1990-01-01@00:00'
|
||
.PP
|
||
\fBSTRING\fR - "" (the empty string)
|
||
.RE
|
||
.PP
|
||
Any value other than the \fIzero value\fR is treated as \fItrue\fR.
|
||
.PP
|
||
.B OPERATORS
|
||
.PP
|
||
\fBRemind\fR has the following operators. Operators on the same line
|
||
have equal precedence, while operators on lower lines have lower precedence
|
||
than those on higher lines. The operators approximately correspond to
|
||
C operators.
|
||
.PP
|
||
.nf
|
||
! - (unary logical negation and arithmetic negation)
|
||
* / % (multiplication, division, modulus)
|
||
+ - (addition/concatenation, subtraction)
|
||
< <= > >= (comparisons)
|
||
== != (equality and inequality tests)
|
||
&& (logical AND)
|
||
|| (logical OR)
|
||
.fi
|
||
.PP
|
||
.B DESCRIPTION OF OPERATORS
|
||
.PP
|
||
.TP
|
||
.B !
|
||
Logical negation. Can be applied to any type. If the operand
|
||
is non-zero, returns 0. Otherwise, returns 1.
|
||
.TP
|
||
.B \-
|
||
Unary minus. Can be applied to an \fBINT\fR. Returns the negative
|
||
of the operand.
|
||
.TP
|
||
.B *
|
||
Multiplication. Returns the product of two \fBINT\fRs. Alternatively, if
|
||
one argument is a \fBSTRING\fR and the other an \fBINT\fR, returns a
|
||
\fBSTRING\fR consisting of the INT number of repeats of the original STRING.
|
||
In this case, the INT argument cannot be negative.
|
||
.TP
|
||
.B /
|
||
Integer division. Returns the quotient of two \fBINT\fRs, discarding the
|
||
remainder.
|
||
.TP
|
||
.B %
|
||
Modulus. Returns the remainder upon dividing one \fBINT\fR by another.
|
||
.TP
|
||
.B +
|
||
Has several uses. These are:
|
||
.PP
|
||
.RS
|
||
\fBINT\fR + \fBINT\fR - returns the sum of two \fBINT\fRs.
|
||
.PP
|
||
\fBINT\fR + \fBTIME\fR or \fBTIME\fR + \fBINT\fR - returns a \fBTIME\fR
|
||
obtained by adding
|
||
\fBINT\fR minutes to the original \fBTIME\fR. The result will always
|
||
range from 00:00 through 23:59.
|
||
.PP
|
||
\fBTIME\fR + \fBTIME\fR treats the second \fBTIME\fR parameter as a
|
||
duration, converting it to an integer number of minutes past midnight,
|
||
and then performs addition as with \fBTIME\fR + \fBINT\fR.
|
||
.PP
|
||
\fBINT\fR + \fBDATE\fR or \fBDATE\fR + \fBINT\fR - returns a \fBDATE\fR
|
||
obtained by adding \fBINT\fR days to the original \fBDATE\fR.
|
||
.PP
|
||
\fBINT\fR + \fBDATETIME\fR or \fBDATETIME\fR + \fBINT\fR - returns a
|
||
\fBDATETIME\fR obtained by adding \fBINT\fR minutes to the original
|
||
\fBDATETIME\fR.
|
||
.PP
|
||
\fBDATETIME\fR + \fBTIME\fR or \fBTIME\fR + \fBDATETIME\fR
|
||
treats the \fBTIME\fR parameter as a
|
||
duration, converting it to an integer number of minutes past midnight,
|
||
and then performs addition as with \fBDATETIME\fR + \fBINT\fR.
|
||
.PP
|
||
\fBSTRING\fR + \fBSTRING\fR - returns a \fBSTRING\fR that is the
|
||
concatenation of the two original
|
||
\fBSTRING\fRs.
|
||
.PP
|
||
\fBSTRING\fR + anything or anything + \fBSTRING\fR -
|
||
converts the non-\fBSTRING\fR
|
||
argument to a \fBSTRING\fR, and then performs concatenation. See
|
||
the \fBcoerce()\fR function.
|
||
.RE
|
||
.TP
|
||
.B \-
|
||
Has several uses. These are:
|
||
.PP
|
||
.RS
|
||
\fBINT\fR - \fBINT\fR - returns the difference of two \fBINT\fRs.
|
||
.PP
|
||
\fBDATE\fR - \fBDATE\fR - returns (as an \fBINT\fR) the difference in days
|
||
between two \fBDATE\fRs.
|
||
.PP
|
||
\fBTIME\fR - \fBTIME\fR - returns (as an \fBINT\fR) the difference in minutes
|
||
between two \fBTIME\fRs.
|
||
.PP
|
||
\fBDATETIME\fR - \fBDATETIME\fR - returns (as an \fBINT\fR) the
|
||
difference in minutes between two \fBDATETIME\fRs.
|
||
.PP
|
||
\fBDATE\fR - \fBINT\fR - returns a \fBDATE\fR that is \fBINT\fR days
|
||
earlier than
|
||
the original \fBDATE\fR.
|
||
.PP
|
||
\fBTIME\fR - \fBINT\fR - returns a \fBTIME\fR that is \fBINT\fR minutes
|
||
earlier
|
||
than the original \fBTIME\fR.
|
||
.PP
|
||
\fBDATETIME\fR - \fBINT\fR - returns a \fBDATETIME\fR that is
|
||
\fBINT\fR minutes earlier than the original \fBDATETIME\fR.
|
||
.PP
|
||
\fBDATETIME\fR - \fBTIME\fR - coerces the \fBTIME\fR to an \fBINT\fR
|
||
and then performs subtraction as above.
|
||
.RE
|
||
.TP
|
||
.B <, <=, >, and >=
|
||
These are the comparison operators. They can take operands of any type,
|
||
but both operands must be of the same type. The comparison operators
|
||
return 1 if the comparison is true, or 0 if it is false. Note that
|
||
string comparison is done following the lexical ordering of
|
||
characters on your system, and that upper and lower case \fIare\fR
|
||
distinct for these operators.
|
||
.TP
|
||
.B ==, !=
|
||
== tests for equality, returning 1 if its operands are equal, and
|
||
0 if they are not. != tests for inequality.
|
||
.PP
|
||
.RS
|
||
If the operands are not of the same type, == returns 0 and != returns
|
||
1. Again, string comparisons are case-sensitive.
|
||
.RE
|
||
.TP
|
||
.B &&
|
||
This is the logical AND operator. Returns the second operand if both
|
||
operands are non-zero. Otherwise, returns whichever operand is zero.
|
||
Operands can be any type and "zero" is interpreted as appropriate for
|
||
each operand's type.
|
||
.TP
|
||
.B ||
|
||
This is the logical OR operator. It returns the first operand that is
|
||
non-zero; if both operands are zero, then returns the second operand.
|
||
Operands can be any type and "zero" is interpreted as appropriate for
|
||
each operand's type.
|
||
.PP
|
||
.B NOTES
|
||
.PP
|
||
If the result of an addition, subtraction or multiplication operation
|
||
would not fit in a C "int" type, \fBRemind\fR issues a "Number too
|
||
high" error. Unlike C, integer operations will not simply give the
|
||
wrong answer in case of overflow.
|
||
.PP
|
||
Operators of equal precedence are \fIalways\fR evaluated from left
|
||
to right, except where parentheses dictate otherwise. This is important,
|
||
because the enhanced "+" operator is not necessarily associative.
|
||
For example:
|
||
.PP
|
||
.nf
|
||
1 + 2 + "string" + 3 + 4 yields "3string34"
|
||
1 + (2 + "string") + (3 + 4) yields "12string7"
|
||
12:59 + 1 + "test" yields "13:00test"
|
||
12:59 + (1 + "test") yields "12:591test"
|
||
.fi
|
||
.PP
|
||
The logical operators are so-called short-circuit operators, as
|
||
they are in C. This means that if the first operand of || is true,
|
||
then the second operand is \fInot\fR evaluated. Similarly, if the first
|
||
operand of && is false, then the second operand is \fInot\fR evaluated.
|
||
.PP
|
||
.B VARIABLES
|
||
.PP
|
||
\fBRemind\fR allows you to assign values to variables. The \fBSET\fR
|
||
command is used as follows:
|
||
.PP
|
||
\fBSET\fR \fIvar\fR \fIexpr\fR
|
||
.PP
|
||
\fIVar\fR is the name of a variable. It must start with a letter or
|
||
underscore, and consist only of letters, digits and underscores. Only
|
||
the first 64 characters of a variable name are significant. Variable
|
||
names are \fInot\fR case sensitive; thus, "Afoo" and "afOo" are the same
|
||
variable. Examples:
|
||
.PP
|
||
.nf
|
||
SET a 10 + (9*8)
|
||
SET b "This is a test"
|
||
SET mydir getenv("HOME")
|
||
SET time 12:15
|
||
SET date today()
|
||
.fi
|
||
.PP
|
||
Note that variables themselves have no type. They take on the type of
|
||
whatever you store in them.
|
||
.PP
|
||
Variables set with SET or on the command-line with \fB\-i\fR\fIvar\fB=\fR\fIexpr\fR
|
||
have global scope.
|
||
.PP
|
||
To delete a variable, use the \fBUNSET\fR command:
|
||
.PP
|
||
\fBUNSET\fR \fIvar\fR [\fIvar\fR...]
|
||
.PP
|
||
For example, to delete all the variables declared above, use:
|
||
.PP
|
||
.nf
|
||
UNSET a b mydir time date
|
||
.fi
|
||
.PP
|
||
.SH SYSTEM VARIABLES
|
||
.PP
|
||
In addition to the regular user variables, \fBRemind\fR has several
|
||
"system variables" that are used to query or control the operating
|
||
state of \fBRemind\fR. System variables are available starting from
|
||
version 03.00.07 of \fBRemind\fR.
|
||
.PP
|
||
All system variables begin with a dollar sign '$'. They can be used
|
||
in \fBSET\fR commands and expressions just as regular variables can.
|
||
All system variables always hold values of a specified type. In
|
||
addition, some system variables cannot be modified, and you cannot
|
||
create new system variables. System variables can be initialized on
|
||
the command line with the \fB\-i\fR option, but you may need to quote
|
||
them to avoid having the shell interpret the dollar sign. System
|
||
variable names are not case-sensitive.
|
||
.PP
|
||
The following system variables are defined. Those marked
|
||
"read-only" cannot be changed with the \fBSET\fR command.
|
||
All system variables hold values of type \fBINT\fR, unless otherwise
|
||
specified.
|
||
.TP
|
||
.B $AddBlankLines
|
||
If set to 1 (the default), then \fBRemind\fR normally prints a blank
|
||
line after the banner and each reminder. (This can be suppressed by
|
||
ending the reminder or banner with a single percent sign.) If
|
||
$AddBlankLines is set to 0, then \fBRemind\fR does not print the blank line.
|
||
In this case, ending a reminder with % has no effect. If you \fIdo\fR
|
||
want a blank line after a reminder, end it with \fB%_\fR to insert a
|
||
newline.
|
||
|
||
.TP
|
||
.B $CalcUTC
|
||
If 1 (the default), then \fBRemind\fR uses C library functions
|
||
to calculate the number of minutes between local and Universal Time
|
||
Coordinated.
|
||
This affects astronomical calculations (\fBsunrise()\fR for example.)
|
||
If 0, then you must supply the number of minutes between local and
|
||
Universal Time Coordinated in the \fB$MinsFromUTC\fR system variable.
|
||
.TP
|
||
.B $CalMode (read-only)
|
||
If non-zero, then the \fB\-c\fR option was supplied on the command line.
|
||
.TP
|
||
.B $CalType (read-only, STRING type)
|
||
If the \fB\-c\fR, \fB\-s\fR or \fB\-p\fR command-line options were
|
||
used, then this variable has the value "monthly". If \fB\-c+\fR,
|
||
\fB\-s+\fR or \fB\-p+\fR were used, then "weekly". Otherwise, "none".
|
||
.TP
|
||
.B $Daemon (read-only)
|
||
If "daemon mode" \fB\-z\fR was invoked, contains the number of
|
||
minutes between wakeups. If not running in daemon mode, contains
|
||
0. In server mode (either \fB-z0\fR or \fB-zj\fR), contains -1.
|
||
.TP
|
||
.B $DateSep (STRING type)
|
||
This variable can be set only to "/" or "-". It holds the character
|
||
used to separate portions of a date when \fBRemind\fR prints a DATE or
|
||
DATETIME value.
|
||
.TP
|
||
.B $DedupeReminders
|
||
If this variable is set to 1, then \fBRemind\fR will suppress duplicate
|
||
reminders. A given reminder is considered to be a duplicate of a
|
||
previous one if it has the \fIexact\fR same trigger date, trigger
|
||
time, and body. By default, this variable is set to 0 and \fBRemind\fR does
|
||
not suppress duplicate reminders.
|
||
.RS
|
||
.PP
|
||
As an example, consider the following reminder file:
|
||
.PP
|
||
.nf
|
||
SET $DedupeReminders 1
|
||
REM Wednesday MSG Phooey
|
||
REM 20 MSG Phooey
|
||
.fi
|
||
.PP
|
||
On Wednesday, 20 November 2024, only \fIone\fR "Phooey" will be issued.
|
||
In December of 2024, "Phooey" will be issued every Wednesday as well
|
||
as on Friday, 20 December 2024
|
||
.PP
|
||
If you set $DedupeReminders to 0, then \fBRemind\fR does not even track
|
||
reminders to detect duplicates. Consider the following example:
|
||
.PP
|
||
.nf
|
||
SET $DedupeReminders 0
|
||
REM Wednesday MSG Hello
|
||
SET $DedupeReminders 1
|
||
REM Wednesday MSG Hello
|
||
.fi
|
||
.PP
|
||
Every Wednesday, \fBRemind\fR will issue \fItwo\fR "Hello" reminders.
|
||
Because $DedupeReminders was 0 when the first "Hello" was issued, it
|
||
won't be tracked for potential duplicates.
|
||
.PP
|
||
Duplicates are detected after all variable expansion and substitutions
|
||
have been done. Consider the following:
|
||
.PP
|
||
.nf
|
||
SET $DedupeReminders 1
|
||
set a "foo"
|
||
REM MSG [a]
|
||
set a "bar"
|
||
REM MSG [a]
|
||
set a "foo"
|
||
REM MSG [a]
|
||
.fi
|
||
.PP
|
||
The first REM will trigger and print "foo". The second will trigger and
|
||
print "bar". The third will not trigger because it's a duplicate of the
|
||
first "foo".
|
||
.RE
|
||
.TP
|
||
.B $DefaultColor (STRING type)
|
||
This variable can be set to a string that has the form of three
|
||
space-separated numbers. Each number must be an integer from 0 to
|
||
255, or all three numbers must be -1. The default value of
|
||
\fB$DefaultColor\fR is "-1 -1 -1", which suppresses default coloring
|
||
of MSG-type reminders. If you set \fB$DefaultColor\fR to any other
|
||
value, then all MSG-, MSF- and CAL-type reminders are effectively
|
||
converted into SPECIAL COLOR reminders whose color value is specified
|
||
by \fB$DefaultColor\fR.
|
||
.RS
|
||
.PP
|
||
Unlike other system variables, the value of \fB$DefaultColor\fR is
|
||
\fInot\fR preserved between calendar iterations; rather, it is reset
|
||
to "-1 -1 -1" at the start of each iteration.
|
||
.RE
|
||
.TP
|
||
.B $DefaultPrio
|
||
The default priority assigned to reminders without a \fBPRIORITY\fR
|
||
clause. You can set this as required to adjust the priorities of
|
||
blocks of reminders without having to type priorities for individual
|
||
reminders. At startup, \fB$DefaultPrio\fR is set to 5000; it can range
|
||
from 0 to 9999.
|
||
.TP
|
||
.B $DefaultDelta
|
||
You can set this variable to a number from 0 through 10000. If set to
|
||
a non-zero number, then \fBRemind\fR triggers any \fBREM\fR statement
|
||
that lacks a delta as if it had a delta of \fB++$DefaultDelta\fR.
|
||
By default, \fB$DefaultDelta\fR is zero.
|
||
.TP
|
||
.B $DefaultTDelta
|
||
The default time delta used if no +N is given in an AT clause. This
|
||
is normally 0, but can be set with the \fB\-tt\fR option or explicitly
|
||
set in your script. If \fB$DefaultDelta\fR is non-zero, you can use an
|
||
explicit delta of +0 in an AT clause to countermand the default delta.
|
||
.TP
|
||
.B $DeltaOverride (read-only)
|
||
If non-zero, corresponds to the \fIn\fR argument given to a
|
||
\fB\-t\fR\fIn\fR command-line option.
|
||
.TP
|
||
.B $DontFork (read-only)
|
||
If non-zero, then the \fB\-c\fR option was supplied on the command line.
|
||
.TP
|
||
.B $DontTrigAts (read-only)
|
||
The number of times that the \fB\-a\fR option was supplied on the
|
||
command line.
|
||
.TP
|
||
.B $DontQueue (read-only)
|
||
If non-zero, then the \fB\-q\fR option was supplied on the command line.
|
||
.TP
|
||
.B $EndSent (STRING type)
|
||
Contains a list of characters that end a sentence. The \fBMSF\fR
|
||
keyword inserts two spaces after these characters. Initially,
|
||
\fB$EndSent\fR is set to ".!?" (period, exclamation mark, and
|
||
question mark.)
|
||
.TP
|
||
.B $EndSentIg (STRING type)
|
||
Contains a list of characters that should be ignored when \fBMSF\fR
|
||
decides whether or not to place two spaces after a sentence. Initially,
|
||
is set to "'>)]}"+CHAR(34) (single-quote, greater-than, right
|
||
parenthesis, right bracket, right brace, and double-quote.)
|
||
.PP
|
||
.RS
|
||
For example, the default values work as follows:
|
||
.PP
|
||
.nf
|
||
MSF He said, "Huh! (Two spaces will follow this.)" Yup.
|
||
.fi
|
||
.PP
|
||
because the final parenthesis and quote are ignored (for the purposes
|
||
of spacing) when they follow a period.
|
||
.RE
|
||
.TP
|
||
.B $ExpressionTimeLimit
|
||
If set to a non-zero value \fIn\fR, than any expression that takes longer than
|
||
\fIn\fR seconds to evaluate will be aborted and an error returned. This is
|
||
to prevent maliciously-crafted expressions for creating a denial-of-service.
|
||
In an included file, $ExpressionTimeLimit can only be lowered from its
|
||
current value. In the top-level file, it can be set to any value, including
|
||
zero to disable the time limit.
|
||
.TP
|
||
.B $FirstIndent
|
||
The number of spaces by which to indent the first line of a \fBMSF\fR-type
|
||
reminder. The default is 0.
|
||
.TP
|
||
.B $FoldYear
|
||
The standard Unix library functions may have difficulty dealing with dates
|
||
later than 2037. If this variable is set to 1, then the UTC calculations
|
||
"fold back" years later than 2037 before using the Unix library functions.
|
||
For example, to find out whether or not daylight saving time is in
|
||
effect in June, 2077, the year is "folded back" to 2027, because both
|
||
years begin on a Friday, and both are non-leapyears. The rules for
|
||
daylight saving time are thus presumed to be identical for both
|
||
years, and the Unix library functions can handle 2027. By default,
|
||
this variable is 0. Set it to 1 if the sun or UTC functions misbehave
|
||
for years greater than 2037. See also the section "MACHINES WITH A
|
||
32-BIT TIME_T TYPE"
|
||
.TP
|
||
.B $FormWidth
|
||
The maximum width of each line of text for formatting \fBMSF\fR-type
|
||
reminders. The default is the width of the terminal in columns, minus
|
||
8, but clamped at a minimum of 20 and a maximum of 500. If standard
|
||
output is not a terminal, then the default is 72.If an \fBMSF\fR-type
|
||
reminder contains a word too long to fit in this width, it will not be
|
||
truncated - the width limit will be ignored.
|
||
.TP
|
||
.B $HideCompletedTodos (read-only)
|
||
If non-zero, then the \fB\-\-hide-completed-todos\fR option was supplied
|
||
on the command line.
|
||
.TP
|
||
.B $HushMode (read-only)
|
||
If non-zero, then the \fB\-h\fR option was supplied on the command line.
|
||
.TP
|
||
.B $IgnoreOnce (read-only)
|
||
If non-zero, then the \fB\-o\fR option was supplied on the command
|
||
line, or implicitly enabled for some other reason. In this case,
|
||
\fBONCE\fR directives will be ignored.
|
||
.TP
|
||
.B $InfDelta (read-only)
|
||
If non-zero, then the \fB\-t\fR option was supplied on the command line,
|
||
with no \fIn\fR argument.
|
||
.TP
|
||
.B $IntMax (read-only)
|
||
The largest representable \fBINT\fR. On a machine with 32-bit signed integers
|
||
using twos-complement representation, this will be 2147483647.
|
||
.TP
|
||
.B $IntMin (read-only)
|
||
The smallest representable \fBINT\fR. On a machine with 32-bit signed integers
|
||
using twos-complement representation, this will be -2147483648.
|
||
.TP
|
||
.B $Latitude (STRING type)
|
||
The latitude of your location, expressed as a string that is a floating-point
|
||
number. Because \fBRemind\fR does not have a native floating-point type,
|
||
we need to express it as a string. $Latitude can range from "-90.0" to
|
||
"90.0", with positive numbers representing points north of the equator
|
||
and negative numbers representing south. Note that regardless of your
|
||
locale, $Latitude is always interpreted in the "C" locale and as such,
|
||
the decimal point must be a period (".").
|
||
.TP
|
||
.B $Longitude (STRING type)
|
||
The longitude of your location, expressed as a string that is a floating-point
|
||
number. Because \fBRemind\fR does not have a native floating-point type,
|
||
we need to express it as a string. $Longitude can range from "-180.0" to
|
||
"180.0", with positive numbers representing points east of the Greenwich
|
||
Meridian and negative numbers representing west. Note that regardless of your
|
||
locale, $Longitude is always interpreted in the "C" locale and as such,
|
||
the decimal point must be a period (".").
|
||
.RS
|
||
.PP
|
||
For example, the coordinates of the Statue of Liberty in New York City
|
||
are approximately set by:
|
||
.PP
|
||
.nf
|
||
SET $Latitude "40.68933"
|
||
SET $Longitude "-74.04454"
|
||
.fi
|
||
.RE
|
||
.TP
|
||
.B $LatDeg, $LatMin, $LatSec (DEPRECATED)
|
||
These specify the latitude of your location. \fB$LatDeg\fR can
|
||
range from \-90 to 90, and the others from \-59 to 59. Northern latitudes
|
||
are positive; southern ones are negative. For southern latitudes, all
|
||
three components should be negative. These three variables
|
||
are deprecated; you should use \fB$Latitude\fR instead.
|
||
.TP
|
||
.B $Location (STRING type)
|
||
This is a string specifying the name of your location. It is usually
|
||
the name of your town or city. It can be set to whatever you like,
|
||
but good style indicates that it should be kept consistent with
|
||
the latitude and longitude system variables.
|
||
.TP
|
||
.B $LongDeg, $LongMin, $LongSec (DEPRECATED)
|
||
These specify the longitude of your location. \fB$LongDeg\fR can
|
||
range from \-180 to 180. Western longitudes are positive; eastern
|
||
ones are negative. Note that all three components should have the
|
||
same sign: All positive for western longitudes and all negative for
|
||
eastern longitudes. Note that for historical reasons, the sign for
|
||
longitude is \fIdifferent\fR from the usual convention! If you find
|
||
the longitude of your location from a search engine, you will most
|
||
likely \fIneed to invert the sign to have it work correctly with
|
||
Remind.\fR These three variables are deprecated; you should use
|
||
\fB$Longitude\fR instead. Note also that \fB$Longitude\fR uses the
|
||
standard convention of negative for western longitudes and positive
|
||
for eastern ones.
|
||
.RS
|
||
.PP
|
||
The latitude and longitude information is required for the functions
|
||
\fBsunrise()\fR and \fBsunset()\fR. Default values can be compiled
|
||
into \fBRemind\fR, or you can \fBSET\fR the correct values at the
|
||
start of your reminder scripts.
|
||
.PP
|
||
Note that setting any of \fB$LongDec\fR, \fB$LongMin\fR and \fB$LongSec\fR
|
||
updates \fB$Longitude\fR correspondingly, and setting \fB$Longitude\fR
|
||
updates \fB$LongDeg\fR, \fB$LongMin\fR and \fB$LongSec\fR. Similar
|
||
rules apply to \fB$Latitude\fR, \fB$LatDeg\fR, \fB$LatMin\fR and \fB$LatSec\fR.
|
||
.RE
|
||
.TP
|
||
.B $JSONMode (read-only)
|
||
If non-zero, then the \fB\-\-json\fR command-line option was supplied.
|
||
.TP
|
||
.B $MaxLateMinutes
|
||
This variable controls how \fBRemind\fR reacts to a computer being suspended
|
||
and then woken. Normally, if a timed reminder is queued and then the
|
||
computer suspended, and then the computer is woken \fIafter\fR the
|
||
timed reminder's trigger time, \fBRemind\fR will trigger the timer anyway,
|
||
despite the fact that the trigger time has already passed.
|
||
.RS
|
||
.PP
|
||
If you set \fB$MaxLateMinutes\fR to a non-zero integer between 1 and 1440,
|
||
then \fBRemind\fR will \fInot\fR trigger a timed reminder whose trigger
|
||
time is more than \fB$MaxLateMinutes\fR minutes in the past.
|
||
.PP
|
||
Note that \fBRemind\fR uses the value of \fB$MaxLateMinutes\fR that is in
|
||
effect when it has finished reading the reminder file and puts itself in
|
||
the background. Generally, you should set \fB$MaxLateMinutes\fR once
|
||
near the beginning of the file and not change it after that.
|
||
.RE
|
||
.TP
|
||
.B $MaxSatIter
|
||
The maximum number of iterations for the \fBSATISFY\fR clause
|
||
(described later.) Must be at least 10. The default value is 10,000.
|
||
.TP
|
||
.B $MaxStringLen
|
||
A limit on the longest string that \fBRemind\fR will allow you
|
||
to create. The default is 65535. If you set \fB$MaxStringLen\fR to 0
|
||
or to -1, then \fBremind\fR will allow you to create arbitrarily-long
|
||
strings, at least until it runs out of memory. We do not recommend
|
||
setting \fB$MaxStringLen\fR to 0 or -1 because it is very easy to write
|
||
code that DOSes \fBRemind\fR in that case.
|
||
.TP
|
||
.B $MinsFromUTC
|
||
The number of minutes between Universal Time Coordinated and local time. If
|
||
\fB$CalcUTC\fR is non-zero, this is calculated upon startup of \fBRemind\fR.
|
||
Otherwise, you must set it explicitly. If \fB$CalcUTC\fR is zero,
|
||
then \fB$MinsFromUTC\fR is used in the astronomical calculations. You
|
||
must adjust it for daylight saving time yourself. Also, if you
|
||
want to initialize \fB$MinsFromUTC\fR
|
||
using the \fB\-i\fR command-line option, you
|
||
must also set \fB$CalcUTC\fR to 0 with the \fB\-i\fR option.
|
||
.TP
|
||
.B $NextMode (read-only)
|
||
If non-zero, then the \fB\-n\fR option was supplied on the command line.
|
||
.TP
|
||
.B $MaxFullOmits (read-only)
|
||
The maximum number of full OMITs allowed (a compiled-in constant.)
|
||
.TP
|
||
.B $MaxPartialOmits (read-only)
|
||
The maximum number of partial OMITs allowed (a compiled-in constant.)
|
||
.TP
|
||
.B $NumFullOmits (read-only)
|
||
The number of full OMITs in the current OMIT context.
|
||
.TP
|
||
.B $NumPartialOmits (read-only)
|
||
The number of partial OMITs in the current OMIT context.
|
||
.TP
|
||
.B $NumQueued (read-only)
|
||
Contains the number of reminders queued so far for background
|
||
timed triggering.
|
||
.TP
|
||
.B $NumTrig (read-only)
|
||
Contains the number of reminders triggered for the current date. One
|
||
use for this variable is as follows: Suppose you wish to shade in
|
||
the box of a PostScript calendar whenever a holiday is triggered. You
|
||
could save the value of \fB$NumTrig\fR in a regular variable
|
||
prior to executing a block of
|
||
holiday reminders. If the value of \fB$NumTrig\fR after the holiday
|
||
block is greater than the saved value, then at least one holiday
|
||
was triggered, and you can execute the command to shade in the
|
||
calendar box. (See the section "Calendar Mode".)
|
||
.PP
|
||
.RS
|
||
Note that \fB$NumTrig\fR is affected \fIonly\fR
|
||
by \fBREM\fR commands; triggers in \fBIFTRIG\fR commands do
|
||
not affect it.
|
||
.RE
|
||
.TP
|
||
.B $OnceFile (STRING type)
|
||
If you set this variable to a non-empty string, then rather than using
|
||
the file access date to determine whether or not to run a ONCE-type
|
||
reminder, \fBRemind\fR will maintain a timestamp in the file \fB$OnceFile\fR.
|
||
This is more reliable than using the access date of the reminder file.
|
||
.RS
|
||
.PP
|
||
If \fB$OnceFile\fR does not exist, then it will be created the first time
|
||
a \fBONCE\fR keyword is processed. The file must be writable by the
|
||
current user. If you try to set \fB$OnceFile\fR \fIafter\fR a \fBONCE\fR
|
||
reminder has already been processed, \fBRemind\fR will issue a warning
|
||
and ignore the attempt to set \fB$OnceFile\fR.
|
||
.RE
|
||
.TP
|
||
.B $ParseUntriggered
|
||
A flag indicating whether or not \fBRemind\fR should fully parse
|
||
\fBREM\fR statements that are not triggered. 0 (the default) means to
|
||
skip parsing them and 1 means to parse them.
|
||
.PP
|
||
.RS
|
||
For example, if we have the following \fBREM\fR statement:
|
||
.PP
|
||
.nf
|
||
REM 2020-01-01 MSG ["bad_expression" / 2]
|
||
.fi
|
||
.PP
|
||
Then if \fB$ParseUntriggered\fR is set to 1, \fBRemind\fR will fully
|
||
parse the line and issue a "Type mismatch" error even if the reminder
|
||
is not triggered. However, if \fB$ParseUntriggered\fR is set to 0,
|
||
the default, then \fBRemind\fR will not issue the error except on
|
||
2020-01-01, when the reminder is triggered.
|
||
.PP
|
||
Keeping \fB$ParseUntriggered\fR at 0 may slightly improve performance,
|
||
at the risk of not catching errors until a reminder is triggered. We recommend
|
||
leaving it set to 0.
|
||
.RE
|
||
.TP
|
||
.B $PrefixLineNo (read-only)
|
||
If non-zero, then the \fB\-l\fR option was supplied on the command line.
|
||
.TP
|
||
.B $PSCal (read-only)
|
||
If non-zero, then the \fB\-p\fR option was supplied on the command line.
|
||
.TP
|
||
.B $RunOff (read-only)
|
||
If non-zero, the \fBRUN\fR directives are disabled.
|
||
.TP
|
||
.B $SimpleCal (read-only)
|
||
Set to a non-zero value if \fIeither\fR of the \fB\-p\fR or \fB\-s\fR
|
||
command-line options was supplied.
|
||
.TP
|
||
.B $SortByDate (read-only)
|
||
Set to 0 if no \fB\-g\fR option is used, 1 if sorting by date in ascending
|
||
order, or 2 if sorting by date in descending order.
|
||
.TP
|
||
.B $SortByPrio (read-only)
|
||
Set to 0 if no \fB\-g\fR option is used, 1 if sorting by priority in ascending
|
||
order, or 2 if sorting by priority in descending order.
|
||
.TP
|
||
.B $SortByTime (read-only)
|
||
Set to 0 if no \fB\-g\fR option is used, 1 if sorting by time in ascending
|
||
order, or 2 if sorting by time in descending order.
|
||
.TP
|
||
.B $SubsIndent
|
||
The number of spaces by which all lines (except the first) of an
|
||
\fBMSF\fR-type reminder should be indented. The default is 0.
|
||
.TP
|
||
.B $SuppressImplicitWarnings
|
||
Normally, \fBRemind\fR issues a warning if a line begins with an unknown
|
||
token and is treated as a \fBREM\fR command, or if a \fBREM\fR command
|
||
is missing a type and is treated as a \fBMSG\fR-type reminder. Setting
|
||
\fB$SuppressImplicitWarnings\fR to 1 suppresses these warnings. The default
|
||
is 0 and we do not recommend disabling the warnings.
|
||
.TP
|
||
.B $SuppressLRM
|
||
Normally, when \fBRemind\fR is run with the \fB\-c\fR option in a UTF-8 locale,
|
||
it emits a left-to-right mark sequence after printing day names or
|
||
reminders. Some terminals render this incorrectly, so you can use:
|
||
.RS
|
||
.PP
|
||
.nf
|
||
SET $SuppressLRM 1
|
||
.fi
|
||
.PP
|
||
at the top of your reminder file to suppress the LRM sequences, or you
|
||
can invoke \fBRemind\fR with the option \fB'\-i$SuppressLRM=1'\fR.
|
||
.RE
|
||
.TP
|
||
.B $SysInclude (read-only, STRING type)
|
||
A directory path containing standard reminder scripts. Currently,
|
||
\fBRemind\fR ships with some standard holiday files and language packs.
|
||
The value of \fB$SysInclude\fR is "@prefix@/share/remind" on
|
||
this installation.
|
||
.TP
|
||
.B $T (read-only, DATE or INT type)
|
||
Equivalent to \fBtrigdate()\fR. (See BUILT-IN FUNCTIONS.)
|
||
.TP
|
||
.B $Tb (read-only, DATE or INT type)
|
||
Equivalent to \fBtrigbase()\fR.
|
||
.TP
|
||
.B $Td (read-only)
|
||
Equivalent to \fBday(trigdate())\fR.
|
||
.TP
|
||
.B $Tm (read-only)
|
||
Equivalent to \fBmonnum(trigdate())\fR.
|
||
.TP
|
||
.B $Tu (read-only, DATE or INT type)
|
||
Equivalent to \fBtriguntil()\fR.
|
||
.TP
|
||
.B $Tw (read-only)
|
||
Equivalent to \fBwkdaynum(trigdate())\fR.
|
||
.TP
|
||
.B $Ty (read-only)
|
||
Equivalent to \fByear(trigdate())\fR.
|
||
.TP
|
||
.B $Tt (read-only, TIME or INT type)
|
||
Equivalent to \fBtrigtime()\fR.
|
||
.TP
|
||
.B $TimeSep (STRING type)
|
||
This variable can be set only to ":" or ".". It holds the character
|
||
used to separate portions of a time when \fBRemind\fR prints a TIME or
|
||
DATETIME value.
|
||
.TP
|
||
.B $TimetIs64bit (read-only)
|
||
This variable returns 1 if the internal C \fBtime_t\fR type is at least
|
||
64 bits long. If it returns 0, then the internal C library is unable
|
||
to represent dates after about 2038, and \fBRemind\fR will use a workaround to avoid
|
||
problems. See also the section "MACHINES WITH A 32-BIT TIME_T TYPE"
|
||
.TP
|
||
.B $TodoFilter (read-only)
|
||
If 0, then both events and TODOs are being output. If 1, then the
|
||
\fB\-\-only-todos\fR command-line option was supplied. If 2, then
|
||
the \fB\-\-only-events\fR command-line option was supplied.
|
||
.TP
|
||
.B $UntimedFirst (read-only)
|
||
Set to 1 if the \fB\-g\fR option is used with a fourth sort character
|
||
of "d"; set to 0 otherwise.
|
||
.TP
|
||
.B $U (read-only, DATE type)
|
||
Exactly equivalent to \fBtoday()\fR. (See BUILT-IN FUNCTIONS.)
|
||
.TP
|
||
.B $Ud (read-only)
|
||
Equivalent to \fBday(today())\fR.
|
||
.TP
|
||
.B $Um (read-only)
|
||
Equivalent to \fBmonnum(today())\fR.
|
||
.TP
|
||
.B $Uw (read-only)
|
||
Equivalent to \fBwkdaynum(today())\fR.
|
||
.TP
|
||
.B $Uy (read-only)
|
||
Equivalent to \fByear(today())\fR.
|
||
.TP
|
||
.B $UseVTColors (read-only)
|
||
Set to 1 if the \fB\-@\fR or \fB\-cc\fR options were used; 0 otherwise.
|
||
.TP
|
||
.B $UseBGVTColors (read-only)
|
||
Set to 1 if the \fB\-@,,1\fR option was used; 0 otherwise.
|
||
.TP
|
||
.B $Use256Colors (read-only)
|
||
Set to 1 if the \fB\-@1\fR option was used; 0 otherwise.
|
||
.TP
|
||
.B $UseTrueColors (read-only)
|
||
Set to 1 if the \fB\-@2\fR option was used; 0 otherwise.
|
||
.TP
|
||
.B $TerminalBackground (read-only)
|
||
Returns -1 if the terminal background color could not be determined, 0
|
||
if it was found to be dark (or was specified as dark with the
|
||
\fB\-@,0\fR option) or 1 if it was found to be light (or specified as
|
||
light with the \fB\-@,1\fR option.) The terminal background is considered
|
||
to be "dark" if the average of the red, green and blue components is
|
||
at most 85 out of 255, and if the maximum of any component is at most
|
||
128 out of 255.
|
||
.TP
|
||
.B $TerminalHyperlinks (INT type)
|
||
If your terminal supports escape sequences to allow HTML-like
|
||
anchors around text (see https://gist.github.com/egmontkob/eb114294efbcd5adb1944c9f3cb5feda), then you can set this variable to 1. \fBRemind\fR will then
|
||
make any reminder with a "Url:" info string into a hyperlink in your
|
||
terminal. By default, \fB$TerminalHyperlinks\fR is set to 1 if \fBRemind\fR's
|
||
standard output is a terminal, or to 0 if it is not.
|
||
.TP
|
||
.B $WarningLevel (STRING type)
|
||
As new versions of \fBRemind\fR are released, new warnings may be added.
|
||
If your formerly-fine scripts suddenly start issuing warnings when you
|
||
upgrade \fBRemind\fR, then as a \fIstopgap\fR measure, you may set
|
||
\fB$WarningLevel\fR to a string of the form \fIAB\fR.\fICD\fR.\fIEF\fR where
|
||
\fIAB\fR, \fICD\fR and \fIEF\fR are pairs of decimal digits. This will
|
||
suppress any warnings that were introduced \fIafter\fR \fBRemind\fR
|
||
version \fIAB\fR.\fICD\fR.\fIEF\fR. If you do not set \fB$WarningLevel\fR, then
|
||
it defaults to the current version of \fBRemind\fR, meaning all warnings
|
||
will be issued.
|
||
.RS
|
||
.PP
|
||
For example, if you want the warnings you receive limited to what
|
||
Remind 05.00.00 would have produced, use:
|
||
.PP
|
||
.nf
|
||
SET $WarningLevel "05.00.00"
|
||
.fi
|
||
.PP
|
||
We do \fInot\fR recommend setting \fB$WarningLevel\fR as a matter
|
||
of course; you should use it to suppress warnings only for as long as
|
||
it takes for you to fix your remind scripts so they no longer cause
|
||
warnings to be emitted.
|
||
.RE
|
||
.PP
|
||
Note: If any of the calendar modes are in effect, then the
|
||
values of $Daemon, $DontFork, $DontTrigAts, $DontQueue, $HushMode,
|
||
$IgnoreOnce, $InfDelta, and $NextMode are not meaningful.
|
||
.PP
|
||
.SH SAVING AND RESTORING VARIABLES
|
||
.PP
|
||
Just as with the OMIT context, you can save and restore the values of
|
||
global variables and all (modifiable) system variables. For example:
|
||
.PP
|
||
.nf
|
||
SET a 1
|
||
UNSET b
|
||
|
||
# Save variables
|
||
PUSH-VARS $DefaultColor $AddBlankLines a b
|
||
|
||
SET $DefaultColor "255 0 0"
|
||
SET $AddBlankLines 0
|
||
SET a 3
|
||
SET b 4
|
||
REM MSG Hello
|
||
|
||
# Restore all the variables we pushed earlier
|
||
POP-VARS
|
||
|
||
# Now the changes to $DefaultColor and $AddBlankLines
|
||
# have been undone. Additionally, a is restored to 1
|
||
# and b is unset
|
||
.fi
|
||
.PP
|
||
As you see from the example, PUSH-VARS takes a list of global variable
|
||
names and/or system variable names. You can save the values of any
|
||
\fImodifiable\fR system variables and any global variable. You can
|
||
even push global variables that are not set.
|
||
.PP
|
||
The POP-VARS command restores the values of all system variables and
|
||
global variables that were pushed by the most recent PUSH-VARS
|
||
command. If you push an undefined global variable, then that variable
|
||
is unset by the POP-VARS command.
|
||
.PP
|
||
.SH BUILT-IN FUNCTIONS
|
||
.PP
|
||
\fBRemind\fR has a plethora of built-in functions. The syntax for a function
|
||
call is the same as in C - the function name, followed a comma-separated list
|
||
of arguments in parentheses. Function names are not case-sensitive. If
|
||
a function takes no arguments, it must be followed by "()" in the function
|
||
call. Otherwise, \fBRemind\fR will interpret it as a variable name,
|
||
and probably not work correctly.
|
||
.PP
|
||
In the descriptions below, short forms are used to denote acceptable
|
||
types for the arguments. The characters "i", "s", "d", "t" and "q" denote
|
||
\fBINT\fR, \fBSTRING\fR, \fBDATE\fR, \fBTIME\fR and \fBDATETIME\fR arguments,
|
||
respectively. If an argument can be one of several types, the characters
|
||
are concatenated. For example, "di_arg" denotes an argument that can be
|
||
a \fBDATE\fR or an \fBINT\fR. "x_arg" denotes an argument that can be
|
||
of any type. The type of the argument is followed by
|
||
an underscore and an identifier naming the argument.
|
||
.PP
|
||
The built-in functions are:
|
||
.TP
|
||
.B _(s_message)
|
||
Returns the translation table entry for \fImessage\fR. If there is no
|
||
such translation table entry, then returns \fImessage\fR unmodified.
|
||
For example, consider this sequence:
|
||
.RS
|
||
.PP
|
||
.nf
|
||
TRANSLATE "Goodbye" "Tot ziens"
|
||
SET a _("Goodbye")
|
||
.fi
|
||
.PP
|
||
After those two lines have been executed, the variable \fBa\fR will be
|
||
set to "Tot ziens". See the section THE TRANSLATION TABLE for more
|
||
information.
|
||
.PP
|
||
In the body of a reminder, the substitution sequence
|
||
\fB%(\fItext\fR\fB)\fR is (almost) the equivalent of
|
||
\fB[_("\fItext\fR\fB")]\fR. Therefore, the following reminders are
|
||
almost equivalent:
|
||
.PP
|
||
.nf
|
||
|
||
REM MSG %(Goodbye)
|
||
REM MSG [_("Goodbye")]
|
||
.fi
|
||
.PP
|
||
The only difference is that if _("Goodbye") contains a \fB%\fR sign,
|
||
then that result will be run through the substitution filter, whereas
|
||
in the first reminder, it will not. That is because the second
|
||
\fBREM\fR command performs expression pasting followed by a
|
||
substitution filter pass, while the first one performs the translation
|
||
as part of the substitution filter (and does not make a second
|
||
substitution filter pass.)
|
||
.RE
|
||
.TP
|
||
.B abs(i_num)
|
||
Returns the absolute value of \fInum\fR.
|
||
.TP
|
||
.B access(s_file, si_mode)
|
||
Tests the access permissions for the file \fIfile\fR. \fIMode\fR can
|
||
be a string, containing a mix of the characters "rwx" for read,
|
||
write and execute permission testing. Alternatively, \fImode\fR can
|
||
be a number as described in the UNIX \fBaccess\fR(2) system call. The
|
||
function returns 0 if the file can be accessed with the specified \fImode\fR,
|
||
and \-1 otherwise.
|
||
.TP
|
||
.B adawn([dq_date])
|
||
Returns the time of "astronomical dawn" on the specified \fIdate\fR. If
|
||
\fIdate\fR is omitted, defaults to \fBtoday()\fR. If a \fIdatetime\fR object
|
||
is supplied, only the date component is used.
|
||
.TP
|
||
.B adusk([dq_date])
|
||
Returns the time of "astronomical twilight" on the specified \fIdate\fR. If
|
||
\fIdate\fR is omitted, defaults to \fBtoday()\fR.
|
||
.TP
|
||
.B ampm(tq_time [,s_am [,s_pm [,i_lz]]])
|
||
Returns a \fBSTRING\fR that is the result of converting \fItime\fR
|
||
(which is either a \fBTIME\fR or a \fBDATETIME\fR object) to "AM/PM"
|
||
format. The optional arguments \fIam\fR and \fIpm\fR are the strings
|
||
to append in the AM and PM case, respectively; they default to "AM"
|
||
and "PM". The optional argument \fIlz\fR specifies whether or not
|
||
the hour should be padded to two digits with a leading zero. If \fIlz\fR is
|
||
zero, then a leading 0 is not added; otherwise, the hour is padded out to
|
||
two digits with a leading zero. If not supplied, \fIlz\fR defaults to zero.
|
||
.RS
|
||
.PP
|
||
The function obeys the system variables $DateSep, $TimeSep and
|
||
$DateTimeSep when formatting its output. Here are some examples of
|
||
its output:
|
||
.PP
|
||
.nf
|
||
ampm(0:22) returns "12:22AM"
|
||
ampm(17:45, "am", "pm") returns "5:45pm"
|
||
ampm(17:45, "am", "pm", 1) returns "05:45pm"
|
||
ampm('2020-03-14@21:34') returns "2020-03-14@9:34PM"
|
||
.fi
|
||
.PP
|
||
.RE
|
||
.TP
|
||
.B ansicolor(i_red, i_green, i_blue [,i_bg [,i_clamp]])
|
||
Returns a \fBSTRING\fR that contains an ANSI escape sequence for changing
|
||
the terminal text color. The parameters \fIred\fR, \fIgreen\fR and \fIblue\fR
|
||
are integers from 0 to 255 specifying the value of the respective color
|
||
component. As a special case, all three values can be -1, in which case
|
||
the ANSI sequence "ESC[0m" is returned, which resets all text attributes
|
||
to normal.
|
||
.RS
|
||
.PP
|
||
The string returned by \fBansicolor\fR depends on the color mode that
|
||
\fBRemind\fR is running in, as specified by the \fB\-@\fR option. If color
|
||
mode is not enabled, then \fBansicolor\fR always returns the empty string.
|
||
Otherwise, it returns the escape sequence that best approximates the color
|
||
according to the \fB\-@\fR color mode.
|
||
.PP
|
||
The optional \fIbg\fR argument is either 0 or 1. If 0 (the default), then
|
||
the foreground color is set. If 1, then the background color is set. Note
|
||
that setting the background color only works in 256-color or true-color
|
||
mode.
|
||
.PP
|
||
The optional \fIclamp\fR argument is either 0 or 1. If 0 (the default),
|
||
then colors are not adjusted based on the terminal background color. If
|
||
1, then \fBRemind\fR attempts to adjust dark or bright colors so they have
|
||
enough contrast to be visible in the terminal.
|
||
.PP
|
||
The first three arguments may alternatively be specified as a string
|
||
consisting of three space-separated numbers, as in this example: "128 128 0"
|
||
.PP
|
||
As a special case, \fBansicolor("")\fR is equivalent to
|
||
\fBansicolor(-1,-1,-1)\fR and returns the ANSI sequence to reset all text
|
||
attributes to normal.
|
||
.PP
|
||
Note that inserting ANSI color sequences in calendar mode \fIwill
|
||
produce garbled results\fR. Therefore, we recommend defining
|
||
functions such as the ones below that return the empty string in
|
||
calendar mode:
|
||
.PP
|
||
.nf
|
||
IF $CalMode
|
||
FSET fg(r,g,b) ""
|
||
FSET bg(r,g,b) ""
|
||
ELSE
|
||
FSET fg(r,g,b) ansicolor(r,g,b)
|
||
FSET bg(r,g,b) ansicolor(r,g,b,1)
|
||
ENDIF
|
||
REM [fg(255,0,0)][bg(64,64,64)]Red on Gray[fg(-1,-1,-1)] in agenda mode
|
||
REM SPECIAL COLOR 0 255 0 Green in agenda and calendar mode
|
||
.fi
|
||
.PP
|
||
If you use the \fBansicolor\fR function, don't forget to reset the color
|
||
back to normal with \fBansicolor(-1,-1,-1)\fR or subsequent reminders
|
||
will continue to be colored.
|
||
.RE
|
||
.TP
|
||
.B args(s_fname)
|
||
Returns the number of arguments expected by the user-defined function
|
||
\fIfname\fR, or \-1 if no such user-defined function exists. Note that
|
||
this function examines only user-defined functions, not built-in functions.
|
||
Its main use is to determine whether or not a particular user-defined
|
||
function has been defined previously. The \fBargs()\fR function is
|
||
available only in versions of \fBRemind\fR from 03.00.04 and up.
|
||
.TP
|
||
.B asc(s_string)
|
||
Returns an \fBINT\fR that is the ASCII code of the first byte in
|
||
\fIstring\fR. As a special case, \fBasc("")\fR returns 0. For UTF-8
|
||
strings, this will return the UTF-8 byte with which the string begins,
|
||
which is not likely to be very useful.
|
||
.TP
|
||
.B codepoint(s_string)
|
||
Returns an \fBINT\fR that is the code point of the first character
|
||
in \fIstring\fR, treating multi-byte characters correctly. As a special case,
|
||
\fBcodepoint("")\fR returns 0.
|
||
.TP
|
||
.B baseyr()
|
||
Returns the "base year" that was compiled into \fBRemind\fR (normally
|
||
1990.) All dates are stored internally as the number of days since
|
||
1 January of \fBbaseyr()\fR.
|
||
.TP
|
||
.B catch(x_arg1, x_arg2)
|
||
Evaluates \fBarg1\fR and if no error occurs, returns the resulting value.
|
||
If an error occurs during the evaluation of \fBarg1\fR, evaluates and
|
||
returns \fBarg2\fR. Note that \fBcatch()\fR can only catch
|
||
run-time \fIevaluation\fR errors. It cannot catch \fIsyntax\fR errors.
|
||
.RS
|
||
.PP
|
||
Here are some examples:
|
||
.PP
|
||
.nf
|
||
catch(4/2, 33) => 2, because 4/2 evaluates without error
|
||
catch(4/0, 33) => 33, because 4/0 gives a divide-by-zero error
|
||
catch(2, 1/0) => 2, and the second argument is not evaluated
|
||
catch(4/0, 1/0) results in a divide-by-zero error
|
||
.fi
|
||
.PP
|
||
Note in the last example that catch does \fInot\fR protect you from errors
|
||
in the evaluation of \fBarg2\fR.
|
||
.RE
|
||
.TP
|
||
.B catcherr()
|
||
Returns a string representing the error message from the most
|
||
recently-evaluated \fBcatch()\fR function whose first argument yielded
|
||
an error. Note that the error message is always in English even if
|
||
\fBRemind\fR has been localized; this lets you reliably test the return
|
||
value. Here are some examples:
|
||
.RS
|
||
.PP
|
||
.nf
|
||
# No "catch" invocations yet: sets a to "Ok"
|
||
set a catcherr()
|
||
|
||
# Sets b to "oops" and a to "Division by zero"
|
||
set b catch(1/0, "oops")
|
||
set a catcherr()
|
||
|
||
# Sets b to 1 and a to "Division by zero". The catch error
|
||
# is never cleared by a non-error catch()
|
||
set b catch(4-3, "not-evaluated")
|
||
set a catcherr()
|
||
.fi
|
||
.RE
|
||
.TP
|
||
.B char(i_i1 [,i_i2...])
|
||
This function can take any number of \fBINT\fR arguments. It returns
|
||
a \fBSTRING\fR consisting of the bytes specified by the arguments.
|
||
It is easy to create invalid UTF-8 sequences; \fBchar\fR does not check
|
||
for this. Note that none of the arguments can be 0, unless there is only one
|
||
argument. As a special case, \fBchar(0)\fR returns "".
|
||
.TP
|
||
.B mbchar(i_i1 [,i_i2...])
|
||
This function can take any number of \fBINT\fR arguments. It returns
|
||
a \fBSTRING\fR consisting of the characters specified by the
|
||
arguments. Any codepoint may be supplied and a correct multi-byte
|
||
character string will be returned. Note that none of the arguments
|
||
can be 0, unless there is only one argument. As a special case,
|
||
\fBmbchar(0)\fR returns "". Additionally, no argument may be a
|
||
negative number.
|
||
.TP
|
||
.B choose(i_index, x_arg1 [,x_arg2...])
|
||
\fBChoose\fR must take at least two arguments, the first of which is
|
||
an \fBINT\fR. If \fIindex\fR is \fIn\fR, then the \fIn\fRth subsequent
|
||
argument is returned. If \fIindex\fR is less than 1, then \fIarg1\fR
|
||
is returned. If \fIindex\fR is greater than the number of subsequent
|
||
arguments, then the last argument is returned. Examples:
|
||
.PP
|
||
.nf
|
||
\fBchoose(0, "foo", 1:13, 1000)\fR returns "foo"
|
||
\fBchoose(1, "foo", 1:13, 1000)\fR returns "foo"
|
||
\fBchoose(2, "foo", 1:13, 1000)\fR returns 1:13
|
||
\fBchoose(3, "foo", 1:13, 1000)\fR returns 1000
|
||
\fBchoose(4, "foo", 1:13, 1000)\fR returns 1000
|
||
.fi
|
||
.RS
|
||
.PP
|
||
Note that only the first argument and the chosen result are
|
||
evaluated. Any non-chosen arguments will not be evaluated.
|
||
.RE
|
||
.TP
|
||
.B coerce(s_type, x_arg)
|
||
This function converts \fIarg\fR to the specified \fItype\fR, if such
|
||
conversion is possible. \fIType\fR must be one of "INT", "STRING",
|
||
"DATE", "TIME" or "DATETIME" (case-insensitive).
|
||
The conversion rules are as follows:
|
||
.RS
|
||
.PP
|
||
If \fIarg\fR is already of the \fItype\fR specified, it is returned
|
||
unchanged.
|
||
.PP
|
||
If \fItype\fR is "STRING", then \fIarg\fR is converted to a string
|
||
consisting of its printed representation.
|
||
.PP
|
||
If \fItype\fR is "DATE", then an \fBINT\fR \fIarg\fR is converted
|
||
by interpreting it as the number of days since 1 January \fBbaseyr()\fR.
|
||
A \fBSTRING\fR \fIarg\fR is converted by attempting to read it as if
|
||
it were a printed date. A \fBDATETIME\fR is converted to a date by
|
||
dropping the time component. A \fBTIME\fR \fIarg\fR cannot be converted to
|
||
a date.
|
||
.PP
|
||
If \fItype\fR is "TIME", then an \fBINT\fR \fIarg\fR is converted
|
||
by interpreting it as the number of minutes since midnight.
|
||
A \fBSTRING\fR \fIarg\fR is converted by attempting to read it as if
|
||
it were a printed time. A \fBDATETIME\fR is converted to a time by
|
||
dropping the date component. A \fBDATE\fR \fIarg\fR cannot be converted to
|
||
a time.
|
||
.PP
|
||
If \fItype\fR is "DATETIME", then an \fBINT\fR \fIarg\fR is converted
|
||
by interpreting it as the number of minutes since midnight, 1 January
|
||
\fBbaseyr()\fR. A \fBSTRING\fR is converted by attempting to read it as if
|
||
it were a printed datetime. Other types cannot be converted to a datetime.
|
||
.PP
|
||
If \fItype\fR is "INT", then \fBDATE\fR, \fBTIME\fR and \fBDATETIME\fR
|
||
arguments are converted using the reverse of procedures described
|
||
above. A \fBSTRING\fR \fIarg\fR is converted by parsing it as an
|
||
integer.
|
||
.RE
|
||
.TP
|
||
.B columns([s_arg])
|
||
If called with no arguments, \fBcolumns()\fR behaves as follows:
|
||
If either standard output or standard error is a TTY, returns the
|
||
width of the terminal in columns. If neither standard output nor
|
||
standard error is a TTY, attempts to open "/dev/tty" to obtain the
|
||
terminal size. If this fails, returns -1.
|
||
.RS
|
||
.PP
|
||
If called with a single string argument, \fBcolumns(str)\fR returns
|
||
the number of columns \fBstr\fR will occupy if printed to a terminal.
|
||
ANSI color-changing sequences occupy zero columns whereas some Unicode
|
||
characters occupy two columns. \fBcolumns(str)\fR takes all of that
|
||
into account. Note that if \fBRemind\fR was compiled without Unicode support,
|
||
\fBcolumns(str)\fR returns a type mismatch error.
|
||
.PP
|
||
The result of \fBcolumns(str)\fR may be less than, equal to, or
|
||
greater than the result of \fBmbstrlen(str)\fR. This is because some
|
||
Unicode characters are so-called combining characters that add one to the
|
||
character length, but don't occupy any columns on their own. And other
|
||
Unicode characters are double-width characters that add one to the
|
||
character length, but two to the number of display columns.
|
||
.RE
|
||
.TP
|
||
.B const(x_arg)
|
||
Evaluates \fIarg\fR and returns it, but also ensures that the result
|
||
is marked "constant". Use with caution; incorrect use could result
|
||
in unwanted reminders being purged in Purge Mode. See also the section
|
||
"NON-CONSTANT EXPRESSIONS"
|
||
.TP
|
||
.B current()
|
||
Returns the current date and time as a DATETIME object. This may be the
|
||
actual date and time, or may be the date and time supplied on the command line.
|
||
.TP
|
||
.B date(i_y, si_m, i_d)
|
||
The \fBdate()\fR function returns a \fBDATE\fR object with the year,
|
||
month and day components specified by \fIy\fR, \fIm\fR and \fId\fR.
|
||
The month can be specified as an integer from 1 to 12, or a string
|
||
that is the name of a month.
|
||
.TP
|
||
.B datepart(dq_datetime)
|
||
Returns a \fBDATE\fR object representing the date portion of
|
||
\fIdatetime\fR.
|
||
.TP
|
||
.B datetime(args)
|
||
The \fBdatetime()\fR function can take anywhere from two to five arguments.
|
||
It always returns a DATETIME generated from its arguments.
|
||
.RS
|
||
.PP
|
||
If you supply two arguments, the first must be a DATE and the second a TIME.
|
||
.PP
|
||
If you supply three arguments, the first
|
||
must be a DATE and the second and third must be INTs. The second and
|
||
third arguments are interpreted as hours and minutes and converted to a TIME.
|
||
.PP
|
||
If you supply four arguments, they are interpreted as year, month, day
|
||
and time. Year and day must be INTs. Month may be an INT from 0 to 12
|
||
or a string naming a month. Time must be a TIME.
|
||
.PP
|
||
Finally, if you supply five arguments, they must all be INTs and are
|
||
interpreted as year, month, day, hour and minute. (Actually, month
|
||
can also be a string that is the name of a month.)
|
||
.RE
|
||
.TP
|
||
.B dawn([dq_date])
|
||
Returns the time of "civil dawn" on the specified \fIdate\fR. If \fIdate\fR
|
||
is omitted, defaults to \fBtoday()\fR. If a \fIdatetime\fR object is
|
||
supplied, only the date component is used.
|
||
.TP
|
||
.B day(dq_date)
|
||
This function takes a \fBDATE\fR or \fBDATETIME\fR as an argument, and
|
||
returns an \fBINT\fR that is the day-of-month component of
|
||
\fIdate\fR.
|
||
.TP
|
||
.B daysinmon(si_m, i_y)\fR or \fB daysinmon(dq_date)\fR
|
||
Returns the number of days in month \fIm\fR (1-12) of the year
|
||
\fIy\fR. The first argument can either be an integer from 1 to 12, or
|
||
a string that is the name of a month. If given a single DATE or
|
||
DATETIME argument, returns the number of days in the month containing
|
||
the argument.
|
||
.TP
|
||
.B defined(s_var)
|
||
Returns 1 if the variable named by \fIvar\fR is defined, or 0 if it is not.
|
||
.RS
|
||
Note that \fBdefined()\fR takes a \fBSTRING\fR argument; thus, to check
|
||
if variable X is defined, use:
|
||
.PP
|
||
.nf
|
||
defined("X")
|
||
.fi
|
||
.PP
|
||
and not:
|
||
.PP
|
||
.nf
|
||
defined(X)
|
||
.fi
|
||
.PP
|
||
The second example will attempt to evaluate X, and will return an
|
||
error if it is undefined or not of type \fBSTRING\fR.
|
||
.RE
|
||
.TP
|
||
.B dosubst(s_str [,d_date [,t_time]]) \fRor\fB dosubst(s_str [,q_datetime])
|
||
Returns a \fBSTRING\fR that is the result of passing \fIstr\fR
|
||
through the substitution filter described earlier. The parameters
|
||
\fIdate\fR and \fItime\fR (or \fIdatetime\fR) establish the effective
|
||
trigger date and time used by the substitution filter. If \fIdate\fR
|
||
and \fItime\fR are omitted, they default to \fBtoday()\fR and
|
||
\fBnow()\fR.
|
||
.RS
|
||
.PP
|
||
Note that if \fIstr\fR does not end with "%", a newline character will be
|
||
added to the end of the result. Also, calling \fBdosubst()\fR with a
|
||
\fIdate\fR that is in the past (i.e., if \fIdate\fR < \fBtoday()\fR)
|
||
will produce undefined results.
|
||
.PP
|
||
\fBDosubst()\fR is only available starting from version 03.00.04 of
|
||
\fBRemind\fR.
|
||
.RE
|
||
.TP
|
||
.B dusk([dq_date])
|
||
Returns the time of "civil twilight" on the specified \fIdate\fR. If
|
||
\fIdate\fR is omitted, defaults to \fBtoday()\fR.
|
||
.TP
|
||
.B easterdate([dqi_arg])
|
||
If \fIarg\fR is an \fBINT\fR, then returns the date of Easter Sunday
|
||
for the specified year. If \fIarg\fR is a \fBDATE\fR or
|
||
\fBDATETIME\fR, then returns the date of the next Easter Sunday on or
|
||
after \fIarg\fR. (The time component of a datetime is ignored.) If \fIarg\fR
|
||
is omitted, then it defaults to \fBtoday()\fR.
|
||
.RS
|
||
.PP
|
||
Note that \fBeasterdate\fR computes the Western Easter. For the Orthodox
|
||
Easter date, see \fBorthodoxeaster\fR.
|
||
.RE
|
||
.TP
|
||
.B escape(s_string [,i_add_quotes])
|
||
Returns a \fBSTRING\fR that is the same as the input string, but with
|
||
all special characters backslashed-escaped. For example, the following
|
||
command:
|
||
.RS
|
||
.PP
|
||
.nf
|
||
set a escape("foo" + char(10) + "bar")
|
||
.fi
|
||
.PP
|
||
will set a to "foo\\nbar" where "\\n" is the literal sequence "\\" followed
|
||
by "n". This is useful if you want to compute a string in a pasted-in
|
||
expression that \fBRemind\fR will then parse as a quoted string again,
|
||
such as in a TRANSLATE command or an INFO clause.
|
||
.PP
|
||
If the optional \fIadd_quotes\fR argument is supplied and is non-zero, then
|
||
the return value from \fBescape\fR will include surrounding double-quotes.
|
||
.RE
|
||
.TP
|
||
.B eval(s_arg)
|
||
Parses the string \fIarg\fR as an expression and evaluates it, returning
|
||
the result. Note that any variable names in the parsed expression refer
|
||
to global variables, not any local variables. For example, consider this:
|
||
.PP
|
||
.RS
|
||
.nf
|
||
SET x 2
|
||
FSET f(x) x + eval("1 + x")
|
||
REM MSG F is [f(9)]
|
||
.fi
|
||
.PP
|
||
The result will be "F is 12" because the reference to \fIx\fR inside the
|
||
\fBeval()\fR argument refers to the \fIglobal\fR variable \fIx\fR and
|
||
not the function argument.
|
||
.PP
|
||
Note that for safety, \fBRUN\fR is disabled during the evaluation of
|
||
\fBeval()\fR, which means you can't use the \fBshell()\fR function from
|
||
within an \fBeval()\fR.
|
||
.PP
|
||
.RE
|
||
.TP
|
||
.B evaltrig(s_trigger [,dq_start])
|
||
Evaluates \fItrigger\fR as if it were a REM or IFTRIG trigger specification
|
||
and returns the trigger date as a \fBDATE\fR (or as a \fBDATETIME\fR if
|
||
there is an \fBAT\fR clause.) Returns a negative \fBINT\fR if no trigger
|
||
could be computed.
|
||
.RS
|
||
.PP
|
||
Normally, \fBevaltrig\fR finds a trigger date on or after today. If
|
||
you supply the \fIstart\fR argument, then it scans starting from there.
|
||
.PP
|
||
For example, the expression:
|
||
.PP
|
||
.nf
|
||
evaltrig("Mon 1", '2008-10-07')
|
||
.fi
|
||
.PP
|
||
returns '2008-11-03', since that is the first date on or after
|
||
7 October 2008 that satisfies "Mon 1".
|
||
.PP
|
||
If you want to see how many days it is from the first Monday in October, 2008
|
||
to the first Monday in November, 2008, use:
|
||
.PP
|
||
.nf
|
||
evaltrig("Mon 1", '2008-11-01') - evaltrig("Mon 1", '2008-10-01')
|
||
.fi
|
||
.PP
|
||
and the answer is 28. The trigger argument to \fBevaltrig\fR can have
|
||
all the usual trigger clauses (\fBOMIT\fR, \fBAT\fR, \fBSKIP\fR, etc.) but
|
||
\fIcannot\fR have a \fBSATISFY\fR, \fBMSG\fR, etc. reminder-type clause.
|
||
.RE
|
||
.TP
|
||
.B filedate(s_filename)
|
||
Returns the modification date of \fIfilename\fR. If \fIfilename\fR
|
||
does not exist, or its modification date is before the year
|
||
\fBbaseyr()\fR, then 1 January of \fBbaseyr()\fR is returned.
|
||
.TP
|
||
.B filedatetime(s_filename)
|
||
Returns the modification date and time of \fIfilename\fR. If \fIfilename\fR
|
||
does not exist, or its modification date is before the year
|
||
\fBbaseyr()\fR, then midnight, 1 January of \fBbaseyr()\fR is returned.
|
||
.TP
|
||
.B filedir()
|
||
Returns the directory that contains the current file being
|
||
processed. It may be a relative or absolute pathname, but
|
||
is guaranteed to be correct for use in an \fBINCLUDE\fR command as
|
||
follows:
|
||
.PP
|
||
.nf
|
||
INCLUDE [filedir()]/stuff
|
||
.fi
|
||
.PP
|
||
.RS
|
||
This includes the file "stuff" in the same directory as the
|
||
current file being processed. Note that this workaround is
|
||
no longer necessary because \fBDO stuff\fR will achieve the
|
||
same goal.
|
||
.PP
|
||
Note that if the currently-processing reminders file was specified as
|
||
a symbolic link, then \fBfiledir()\fR returns the directory containing
|
||
the symbolic link and \fInot\fR the directory containing the target
|
||
of the symbolic link. You should avoid using
|
||
symbolic links to files unless both the symbolic link and its target
|
||
happen to be in the same directory.
|
||
.RE
|
||
.TP
|
||
.B filename()
|
||
Returns (as a \fBSTRING\fR) the name of the current file being processed
|
||
by \fBRemind\fR. Inside included files, returns the name of the
|
||
included file.
|
||
.TP
|
||
.B getenv(s_envvar)
|
||
Similar to the \fBgetenv\fR(2) system call. Returns a string representing
|
||
the value of the specified environment variable. Returns "" if the
|
||
environment variable is not defined. Note that the names of environment
|
||
variables are generally case-sensitive; thus, getenv("HOME") is not
|
||
the same as getenv("home").
|
||
.TP
|
||
.B hebdate(i_day, s_hebmon [,idq_yrstart [,i_jahr [,i_aflag]]])
|
||
Support for Hebrew dates - see the section "THE HEBREW CALENDAR"
|
||
.TP
|
||
.B hebday(dq_date)
|
||
Support for Hebrew dates - see the section "THE HEBREW CALENDAR"
|
||
.TP
|
||
.B hebmon(dq_date)
|
||
Support for Hebrew dates - see the section "THE HEBREW CALENDAR"
|
||
.TP
|
||
.B hebyear(dq_date)
|
||
Support for Hebrew dates - see the section "THE HEBREW CALENDAR"
|
||
.TP
|
||
.B hex(i_n)
|
||
Returns a \fBSTRING\fR that is the hexadecimal representation of \fIn\fR.
|
||
There is no "0x" prefix and any letters in the returned value
|
||
are uppper-case.
|
||
.TP
|
||
.B hour(tq_time)
|
||
Returns the hour component of \fItime\fR.
|
||
.TP
|
||
.B htmlescape(s_str)
|
||
Returns a modified copy of \fIstr\fR where "<" is replaced with
|
||
"<"; ">" is replaced with ">" and "&" is replaced with "&"
|
||
.TP
|
||
.B htmlstriptags(s_str)
|
||
Returns a modified copy of \fIstr\fR where HTML tags are stripped
|
||
out. The stripping algorithm is fairly naive; the function starts
|
||
stripping characters when it encounters a "<" and it stops stripping
|
||
when it encounters a ">".
|
||
.TP
|
||
.B iif(x_test1, x_arg1, [x_test2, x_arg2,...], x_default)
|
||
If \fItest1\fR is true, returns \fIarg1\fR. Otherwise, if \fItest2\fR
|
||
is true, returns \fIarg2\fR, and so on. If all of the \fItest\fR
|
||
arguments are false, returns \fIdefault\fR. Note that only
|
||
those arguments needed to determine the final result are
|
||
evaluated. This function accepts an odd number of
|
||
arguments - note that prior to version 03.00.05 of \fBRemind\fR, it
|
||
accepted 3 arguments only. The 3-argument version of \fBiif()\fR is
|
||
compatible with previous versions of \fBRemind\fR.
|
||
.TP
|
||
.B index(s_search, s_target [,i_start)
|
||
Returns an \fBINT\fR that is the location of \fItarget\fR in the
|
||
string \fIsearch\fR. Note that \fBindex\fR uses \fIbyte\fR positions,
|
||
not character positions, so should not be used on non-ASCII strings. Use
|
||
\fBmbindex\fR for non-ASCII strings.
|
||
.RS
|
||
.PP
|
||
The first byte of a string is numbered 1. If \fItarget\fR does not
|
||
exist in \fIsearch\fR, then 0 is returned.
|
||
.PP
|
||
The optional parameter \fIstart\fR specifies the position in
|
||
\fIsearch\fR at which to start looking for \fItarget\fR.
|
||
.RE
|
||
.TP
|
||
.B mbindex(s_search, s_target [,i_start])
|
||
Similar to \fBindex()\fR but returns the \fIcharacter\fR position rather
|
||
than the \fIbyte\fR position. Also, \fIstart\fR is interpreted as a
|
||
1-based character index rather than a byte index.
|
||
.TP
|
||
.B isany(arg1 [,arg2, ..., argN]);
|
||
Returns 1 if the first argument \fIarg1\fR is equal to any of the
|
||
subsequent arguments \fIarg2\fR through \fIargN\fR; returns 0 otherwise.
|
||
Also returns 0 if called with only one argument.
|
||
.RS
|
||
.PP
|
||
As an example, the following two expressions are equivalent:
|
||
.PP
|
||
.nf
|
||
(a == b) || (a == c) || (a == d) || (a == e)
|
||
|
||
isany(a, b, c, d, e)
|
||
.fi
|
||
.RE
|
||
.TP
|
||
.B isconst(x_any)
|
||
Evaluates its argument and then \fIthrows away\fR the value, returning
|
||
1 if the expression is constant or 0 if it is non-constant. Note that
|
||
\fBisconst\fR does not take into account the context; if \fIarg\fR is
|
||
a constant expression but evaluated in a non-constant context,
|
||
\fBisconst\fR will still return 1. For details about constant vs.
|
||
non-constant expressions, see the section "NON-CONSTANT EXPRESSIONS"
|
||
.TP
|
||
.B isdst([d_date [,t_time]]) \fRor\fB isdst(q_datetime)
|
||
Returns a positive number if daylight saving time is in
|
||
effect on the specified date and time. \fIDate\fR
|
||
defaults to \fBtoday()\fR and \fItime\fR defaults to midnight.
|
||
.RS
|
||
.PP
|
||
Note that this function is only as reliable as the C run-time library
|
||
functions. It is available starting with version 03.00.07 of \fBRemind\fR.
|
||
.RE
|
||
.TP
|
||
.B isleap(idq_arg)
|
||
Returns 1 if \fIarg\fR is a leap year, and 0 otherwise. \fIArg\fR can
|
||
be an \fBINT\fR, \fBDATE\fR or \fBDATETIME\fR object. If a \fBDATE\fR
|
||
or \fBDATETIME\fR is supplied, then the year component is used in the test.
|
||
.TP
|
||
.B isomitted(dq_date)
|
||
Returns 1 if \fIdate\fR is omitted, given the current global \fBOMIT\fR
|
||
context. Returns 0 otherwise. (If a datetime is supplied, only the
|
||
date part is used.) Note that any local \fBOMIT\fR or \fBOMITFUNC\fR
|
||
clauses are \fInot\fR taken into account by this function.
|
||
.TP
|
||
.B language()
|
||
Returns a \fBSTRING\fR naming the compiled-in language supported by
|
||
\fBRemind\fR. \fBRemind\fR used to support compiled-in support for other
|
||
languages, but now all localization is done at run-time. As such,
|
||
this function always returns "English". However, the expression
|
||
\fB_("LANGID")\fR returns the two-character ISO 639 language code
|
||
of any language pack in effect, assuming the language pack author has
|
||
written the localization correctly!
|
||
.TP
|
||
.B localtoutc(q_datetime)
|
||
Given a \fBDATETIME\fR object interpreted in the local time zone, return
|
||
a \fBDATETIME\fR object that expresses the same time in UTC.
|
||
.TP
|
||
.B lower(s_string)
|
||
Returns a \fBSTRING\fR with all upper-case characters in \fIstring\fR
|
||
converted to lower-case.
|
||
.TP
|
||
.B max(x_arg1 [,x_arg2...)
|
||
Can take any number of arguments, and returns the maximum. The arguments
|
||
can be of any type, but must all be of the same type. They are compared
|
||
as with the > operator.
|
||
.TP
|
||
.B min(x_arg1 [,x_arg2...)
|
||
Can take any number of arguments, and returns the minimum. The arguments
|
||
can be of any type, but must all be of the same type. They are compared
|
||
as with the < operator.
|
||
.TP
|
||
.B minsfromutc([d_date [,t_time]]) \fRor\fB minsfromutc(q_datetime)
|
||
Returns the number of minutes from Universal Time Coordinated
|
||
(formerly GMT) to
|
||
local time on the specified date and time. \fIDate\fR defaults to
|
||
\fBtoday()\fR and \fItime\fR defaults to midnight. If local time
|
||
is before UTC, the result is negative. Otherwise, the result is
|
||
positive.
|
||
.RS
|
||
.PP
|
||
Note that this function is only as reliable as the C run-time library
|
||
functions. It is available starting with version 03.00.07 of \fBRemind\fR.
|
||
.RE
|
||
.TP
|
||
.B minute(tq_time)
|
||
Returns the minute component of \fItime\fR.
|
||
.TP
|
||
.B mon(dqis_arg)
|
||
If \fIarg\fR is of \fBDATE\fR or \fBDATETIME\fR type, returns a string
|
||
that names the month component of the date. If \fIarg\fR is an
|
||
\fBINT\fR from 1 to 12, returns a string that names the month. If \fIarg\fR
|
||
is a \fBSTRING\fR, returns the name of the month. This last case might
|
||
sound silly, but for example:
|
||
.RS
|
||
.PP
|
||
.nf
|
||
mon("Mar")
|
||
.fi
|
||
.PP
|
||
will return "March", the full name of the month.
|
||
.RE
|
||
.TP
|
||
.B monnum(dq_date)\fR or \fBmonnum(s_str)\fR
|
||
Returns an \fBINT\fR from 1 to 12, representing the month component of
|
||
\fIdate\fR. If a \fBSTRING\fR is supplied rather than a \fBDATE\fR or
|
||
\fBDATETIME\fR, then if \fIstr\fR is a valid month name (or minimum
|
||
3-character abbreviation of a month name) then the corresponding month
|
||
number is returned. If \fIstr\fR is not a valid month name, then an
|
||
error occurs.
|
||
.TP
|
||
.B moondate(i_phase [,d_date [,t_time]]) \fRor\fB moondate(i_phase, q_datetime)
|
||
This function returns the date of the first occurrence of the phase
|
||
\fIphase\fR of the moon on or after \fIdate\fR and \fItime\fR.
|
||
\fIPhase\fR can range from 0 to 3, with 0 signifying new moon, 1 first
|
||
quarter, 2 full moon, and 3 third quarter. If \fIdate\fR is omitted,
|
||
it defaults to \fBtoday()\fR. If \fItime\fR is omitted, it defaults
|
||
to midnight.
|
||
.RS
|
||
.PP
|
||
For example, the following returns the date of the next full moon:
|
||
.PP
|
||
.nf
|
||
SET fullmoon moondate(2)
|
||
.fi
|
||
.PP
|
||
.RE
|
||
.TP
|
||
.B moontime(i_phase [,d_date [,t_time]]) \fRor\fB moontime(i_phase, q_datetime)
|
||
This function returns the time of the first occurrence of the phase
|
||
\fIphase\fR of the moon on or after \fIdate\fR and \fItime\fR.
|
||
\fIPhase\fR can range from 0 to 3, with 0 signifying new moon, 1 first
|
||
quarter, 2 full moon, and 3 third quarter. If \fIdate\fR is omitted,
|
||
it defaults to \fBtoday()\fR. If \fItime\fR is omitted, it defaults
|
||
to midnight. \fBMoontime()\fR is intended to be used in conjunction
|
||
with \fBmoondate()\fR. The \fBmoondate()\fR and \fBmoontime()\fR
|
||
functions are accurate to within a couple of minutes of the
|
||
times in "Old Farmer's Almanac" for Ottawa, Ontario.
|
||
.RS
|
||
.PP
|
||
For example, the following returns the date and time of the next full moon:
|
||
.PP
|
||
.nf
|
||
MSG Next full moon at [moontime(2)] on [moondate(2)]
|
||
.fi
|
||
.PP
|
||
.RE
|
||
.TP
|
||
.B moondatetime(i_phase [,d_date [,t_time]]) \fRor\fB moondatetime(i_phase, q_datetime)
|
||
This function is similar to \fBmoondate\fR and \fBmoontime\fR, but returns
|
||
a DATETIME result.
|
||
.TP
|
||
.B moonphase([d_date [,t_time]]) \fRor\fB moonphase(q_datetime)
|
||
This function returns the phase of the moon on \fIdate\fR and \fItime\fR,
|
||
which default to \fBtoday()\fR and midnight, respectively. The returned
|
||
value is an integer from 0 to 359, representing the phase of the moon
|
||
in degrees. 0 is a new moon, 180 is a full moon, 90 is first-quarter, etc.
|
||
.TP
|
||
.B moonrise([d_date])
|
||
This function returns a DATETIME result giving the date and time of the
|
||
first moonrise on or after midnight on \fIdate\fR. If \fIdate\fR is not
|
||
supplied, it defaults to \fBtoday()\fR.
|
||
.RS
|
||
.PP
|
||
Note that it is not uncommon for a day to have no moonrise, so the date
|
||
part of the return value may not be the same as the \fIdate\fR argument.
|
||
So if you want a calendar of moonrise times, you could use something
|
||
like this:
|
||
.PP
|
||
.nf
|
||
SET mr moonrise()
|
||
IF datepart(mr) == today()
|
||
REM NOQUEUE [mr] MSG Moon rises at %3.
|
||
ELSE
|
||
REM MSG No moonrise today
|
||
ENDIF
|
||
.fi
|
||
.PP
|
||
.RE
|
||
.TP
|
||
.B moonrisedir([d_date])
|
||
This function returns an INT result giving the direction from which
|
||
the moon will rise on the first moonrise on or after midnight on
|
||
\fIdate\fR. If \fIdate\fR is not supplied, it defaults to
|
||
\fBtoday()\fR. The return value ranges from 0 to 359, where 0 is North,
|
||
90 is East, 180 is South and 270 is West.
|
||
.TP
|
||
.B moonset([d_date])
|
||
This function is analogous to \fBmoonrise()\fR but returns the DATETIME of
|
||
the next moonset on or after midnight on \fIdate\fR.
|
||
.TP
|
||
.B moonsetdir([d_date])
|
||
This function is analogous to \fBmoonrisedir()\fR but returns the
|
||
direction of moonset.
|
||
.TP
|
||
.B multitrig(s_trig1 [,s_trig2, [... s_trigN]])
|
||
\fBmultitrig\fR evaluates each string as a trigger, similar to \fBevaltrig\fR,
|
||
and returns the \fIearliest\fR trigger date that is on or after \fBtoday()\fR.
|
||
\fBmultitrig\fR is similar to \fBtrig\fR but has the following difference:
|
||
.RS
|
||
.PP
|
||
\fBtrig\fR returns the \fIfirst\fR trigger date that would have triggered today,
|
||
whereas \fBmultitrig\fR returns the \fIearliest\fR trigger date later than
|
||
today, regardless of whether it would have triggered today.
|
||
.PP
|
||
If no trigger can be computed that is later than \fBtoday()\fR, then
|
||
\fBmultitrig\fR returns 1990-01-01.
|
||
.PP
|
||
Consider the following examples, assuming that today is Sunday, 24 March 2024:
|
||
.PP
|
||
.nf
|
||
# Returns 1990-01-01 because neither would trigger today
|
||
SET a trig("Mon", "Wed")
|
||
|
||
# Returns 2024-03-25 because it's the earlier trigger date
|
||
SET a multitrig("Mon", "Wed")
|
||
|
||
# Returns 2024-03-27 because it's the first that would trigger today
|
||
SET a trig("Wed +3", "Mon +3")
|
||
|
||
# Returns 2024-03-25 because it's the earlier trigger date
|
||
SET a multitrig("Wed +3", "Mon +3")
|
||
|
||
# Returns 1990-01-01 because all triggers have expired
|
||
SET a multitrig("2000", "2022", "1998", "2023")
|
||
.fi
|
||
.PP
|
||
In general, \fBmultitrig\fR works better with the \fBRemind\fR algorithm than
|
||
\fBtrig\fR and should be used most of the time. As an example, this
|
||
reminder is issued at the end of each quarter:
|
||
.PP
|
||
.nf
|
||
REM [multitrig("Mar 31", "Jun 30", "Sep 30", "Dec 31")] +7 MSG \\
|
||
%"End of [ord($Tm/3)] quarter%" is %b.
|
||
.fi
|
||
.PP
|
||
If you want the last working day of each quarter, you could use:
|
||
.PP
|
||
.nf
|
||
PUSH-OMIT-CONTEXT
|
||
OMIT Sat Sun
|
||
REM [multitrig("Mar ~1", "Jun ~1", "Sep ~1", "Dec ~1")] +7 MSG \\
|
||
%"Last working day of [ord($Tm/3)] quarter%" is %b.
|
||
POP-OMIT-CONTEXT
|
||
.fi
|
||
.PP
|
||
Note that unlike \fBevaltrig\fR, \fBmultitrig\fR always returns a \fBDATE\fR
|
||
and never a \fBDATETIME\fR. Including an \fBAT\fR clause in a trigger
|
||
supplied to \fBmultitrig\fR will result in an error.
|
||
.RE
|
||
.TP
|
||
.B ndawn([dq_date])
|
||
Returns the time of "nautical dawn" on the specified \fIdate\fR. If
|
||
\fIdate\fR is omitted, defaults to \fBtoday()\fR. If a \fIdatetime\fR object
|
||
is supplied, only the date component is used.
|
||
.TP
|
||
.B ndusk([dq_date])
|
||
Returns the time of "nautical twilight" on the specified \fIdate\fR. If
|
||
\fIdate\fR is omitted, defaults to \fBtoday()\fR.
|
||
.TP
|
||
.B nonomitted(dq_start, dq_end [, i_step] [,s_wkday...])
|
||
This function returns the number of \fInon-\fRomitted days between
|
||
\fIstart\fR and \fIend\fR. If \fIstart\fR is non-omitted, then it is
|
||
counted. \fIend\fR is never counted.
|
||
.RS
|
||
.PP
|
||
Note that if \fIend\fR is less than \fIstart\fR, the arguments
|
||
are effectively swapped, so counting always begins from the older
|
||
date.
|
||
.PP
|
||
If the third argument to \fBnonomitted\fR is an \fBINT\fR, then it must
|
||
be greater than zero, and is considered to be the \fIstep\fR by which
|
||
\fBnonomitted\fR counts. For example the following expression:
|
||
.PP
|
||
.nf
|
||
nonomitted('2023-07-01', '2023-07-29', 7)
|
||
.fi
|
||
.PP
|
||
returns the number of non-omitted Saturdays from 2023-07-01 up to
|
||
(but not including) 2023-07-29. (Both 2023-07-01 and 2023-07-29 are
|
||
Saturdays.)
|
||
.PP
|
||
If no \fIstep\fR argument is supplied, then a step of 1 is used.
|
||
.PP
|
||
In addition to using the global OMIT context, you
|
||
can supply additional arguments that are names of weekdays to be
|
||
omitted. However, in a \fBREM\fR command, any local \fBOMITFUNC\fR
|
||
clause is \fInot\fR taken into account by this function.
|
||
.PP
|
||
For example, the following line sets a to 11 (assuming no global OMITs):
|
||
.PP
|
||
.nf
|
||
set a nonomitted('2007-08-01', '2007-08-16', "Sat", "Sun")
|
||
.fi
|
||
.PP
|
||
because Thursday, 16 August 2007 is the 11th working day (not counting
|
||
Saturday and Sunday) after Wednesday, 1 August 2007.
|
||
.PP
|
||
\fBnonomitted\fR has various uses. For example, many schools
|
||
run on a six-day cycle and the day number is not incremented on holidays.
|
||
Suppose the school year starts with Day 1 on 4 September 2007. The following
|
||
reminder will label day numbers in a calendar:
|
||
.PP
|
||
.nf
|
||
IF today() >= '2007-09-04'
|
||
set daynum nonomitted('2007-09-04', today(), "Sat", "Sun")
|
||
REM OMIT SAT SUN SKIP CAL Day [(daynum % 6) + 1]
|
||
ENDIF
|
||
.fi
|
||
.PP
|
||
Obviously, the answer you get from \fBnonomitted\fR depends on the global
|
||
OMIT context. If you use movable OMITs, you may get inconsistent results.
|
||
.PP
|
||
Here is a more complex use for \fBnonomitted\fR. My garbage collection
|
||
follows two interleaved 14-day cycles: One Friday, garbage and paper
|
||
recycling ("Black Box") are collected. The next Friday, garbage and
|
||
plastic recycling ("Blue Box") are collected. If any of Monday-Friday
|
||
is a holiday, collection is delayed until the Saturday. Here's a way
|
||
to encode these rules:
|
||
.PP
|
||
.nf
|
||
fset _garbhol(x) wkdaynum(x) == 5 && nonomitted(x-4, x+1) < 5
|
||
REM 12 November 1999 *14 AFTER OMITFUNC _garbhol MSG Black Box
|
||
REM 19 November 1999 *14 AFTER OMITFUNC _garbhol MSG Blue Box
|
||
.fi
|
||
.PP
|
||
Here's how it works: The _garbhol(x) user-defined function returns 1
|
||
if and only if (1) \fIx\fR is a Friday and (2) there is at least one
|
||
OMITted day from the previous Monday up to and including the Friday.
|
||
.PP
|
||
The first REM statement sets up the 14-day black-box cycle. The AFTER
|
||
keyword makes it move collection to the Saturday if _garbhol returns 1.
|
||
The second REM statement sets up the 14-day blue-box cycle with a similar
|
||
adjustment made by AFTER in conjunction with _garbhol.
|
||
.RE
|
||
.TP
|
||
.B nonconst(x_arg)
|
||
Returns the argument \fIarg\fR unchanged, but forces the expression
|
||
to be considered \fInon-constant\fR. For details, see the section
|
||
"NON-CONSTANT EXPRESSIONS"
|
||
.TP
|
||
.B now()
|
||
Returns the current system time, as a \fBTIME\fR type. This may be
|
||
the actual time, or a time supplied on the command line. Note that
|
||
in Calendar Mode, \fBnow()\fR always returns 00:00.
|
||
.TP
|
||
.B ord(i_num)
|
||
Returns a string that is the ordinal number \fInum\fR. For example,
|
||
\fBord(2)\fR returns "2nd", and \fBord(213)\fR returns "213th".
|
||
.RS
|
||
.PP
|
||
In order to help with localization, if you define a function called
|
||
\fBordx\fR that takes a single parameter, then calling
|
||
\fBord\fR(\fIn\fR) invokes \fBordx\fR(\fIn\fR) and returns whatever
|
||
it does. During the callback to \fBordx\fR, \fBRUN\fR will be disabled.
|
||
.RE
|
||
.TP
|
||
.B orthodoxeaster([dqi_arg])
|
||
If \fIarg\fR is an \fBINT\fR, then returns the date of Orthodox Easter Sunday
|
||
for the specified year. If \fIarg\fR is a \fBDATE\fR or
|
||
\fBDATETIME\fR, then returns the date of the next Orthodox Easter Sunday on or
|
||
after \fIarg\fR. (The time component of a datetime is ignored.) If \fIarg\fR
|
||
is omitted, then it defaults to \fBtoday()\fR.
|
||
.RS
|
||
.PP
|
||
Note that \fBorthodoxeaster\fR computes the Orthodox Easter. For the Western
|
||
Easter date, see \fBeasterdate\fR.
|
||
.RE
|
||
.TP
|
||
.B ostype()
|
||
Returns "UNIX". \fBRemind\fR used to run on OS/2 and MS-DOS, but does not
|
||
any longer.
|
||
.TP
|
||
.B pad(x_arg, s_padstr, i_len [, i_right])
|
||
Converts the first argument \fIarg\fR to a string if necessary, and
|
||
then if it is shorter than \fIlen\fR bytes, pads to to
|
||
\fIlen\fR bytes using as many copies (including partial copies)
|
||
of \fIpadstr\fR as necessary. By default, the string is left-padded,
|
||
but if \fIright\fR is supplied and non-zero, the string will
|
||
be right-padded.
|
||
.RS
|
||
.PP
|
||
Here are some examples:
|
||
.PP
|
||
.nf
|
||
pad(3, "0", 2) --> "03"
|
||
pad(465, "0", 2) --> "465"
|
||
pad("foo", " ", 5) --> " foo"
|
||
pad("foo", " ", 5, 1) --> "foo "
|
||
pad("foo", "bar", 11) --> "barbarbafoo"
|
||
.fi
|
||
.RE
|
||
|
||
.TP
|
||
.B mbpad(x_arg, s_padstr, i_len [, i_right])
|
||
This is the multibyte counterpart to \fBpad\fR. The length is
|
||
specified in characters rather than bytes. Use \fBmbpad\fR rather
|
||
than \fBpad\fR if either of the strings contains non-ASCII characters.
|
||
.TP
|
||
.B plural(i_num [,s_str1 [,s_str2]])
|
||
Can take from one to three arguments. If one argument is supplied, returns
|
||
"s" if \fInum\fR is not 1, and "" if \fInum\fR is 1.
|
||
.RS
|
||
.PP
|
||
If two arguments are supplied, returns \fIstr1\fR + "s" if \fInum\fR is
|
||
not 1. Otherwise, returns \fIstr1\fR.
|
||
.PP
|
||
If three arguments are supplied, returns \fIstr1\fR if \fInum\fR is 1, and
|
||
\fIstr2\fR otherwise.
|
||
.RE
|
||
.TP
|
||
.B psmoon(i_phase [,i_size [,s_note [,i_notesize]]])
|
||
[DEPRECATED] Returns a \fBSTRING\fR consisting of PostScript code to
|
||
draw a moon in the upper-left hand corner of the calendar box.
|
||
\fIPhase\fR specifies the phase of the moon, and is 0 (new moon), 1
|
||
(first quarter), 2 (full moon) or 3 (third quarter). If \fIsize\fR is
|
||
specified, it controls the radius of the moon in PostScript units
|
||
(1/72 inch.) If it is not specified or is negative, the size of the
|
||
day-number font is used.
|
||
.PP
|
||
.PP
|
||
.RS
|
||
For example, the following four lines place moon symbols on the PostScript
|
||
calendar:
|
||
.PP
|
||
.nf
|
||
REM [moondate(0)] PS [psmoon(0)]
|
||
REM [moondate(1)] PS [psmoon(1)]
|
||
REM [moondate(2)] PS [psmoon(2)]
|
||
REM [moondate(3)] PS [psmoon(3)]
|
||
.fi
|
||
.PP
|
||
If \fInote\fR is specified, the text is used to annotate the moon
|
||
display. The font is the same font used for calendar entries. If
|
||
\fInotesize\fR is given, it specifies the font size to use for the
|
||
annotation, in PostScript units (1/72 inch.) If \fInotesize\fR is not
|
||
given, it defaults to the size used for calendar entries. (If you annotate
|
||
the display, be careful not to overwrite the day number -- \fBRemind\fR
|
||
does not check for this.) For example, if you want the time of each new
|
||
moon displayed, you could use this in your reminder script:
|
||
.PP
|
||
.nf
|
||
REM [moondate(0)] PS [psmoon(0, \-1, moontime(0)+"")]
|
||
.fi
|
||
.PP
|
||
Note how the time is coerced to a string by concatenating the null string.
|
||
.RE
|
||
.TP
|
||
\fBpsshade(i_gray)\fR or \fBpsshade(i_red, i_green, i_blue)\fR
|
||
[DEPRECATED] Returns a \fBSTRING\fR that consists of PostScript commands to
|
||
shade a calendar box. \fINum\fR can range from 0 (completely black)
|
||
to 100 (completely white.) If three arguments are given, they specify
|
||
red, green and blue intensity from 0 to 100.
|
||
Here's an example of how to use this:
|
||
.RS
|
||
.PP
|
||
.nf
|
||
REM Sat Sun PS [psshade(95)]
|
||
.fi
|
||
.PP
|
||
The above command emits PostScript code to lightly shade the boxes
|
||
for Saturday and Sunday in a PostScript calendar.
|
||
.PP
|
||
Note that \fBpsmoon\fR and \fBpsshade\fR are deprecated; instead
|
||
you should use the SPECIAL SHADE and SPECIAL MOON reminders
|
||
as described in "Out-of-Band Reminders."
|
||
.RE
|
||
.TP
|
||
.B realcurrent()
|
||
Returns (as a DATETIME) the true date and time of day as provided by
|
||
the operating system. This is in contrast to \fBcurrent()\fR, which
|
||
may return a time supplied on the command line.
|
||
.TP
|
||
.B realnow()
|
||
Returns the true time of day as provided by the operating system.
|
||
This is in contrast to \fBnow()\fR, which may return a time supplied
|
||
on the command line, or 00:00 in Calendar Mode.
|
||
.TP
|
||
.B realtoday()
|
||
Returns the date as provided by the operating system. This is in contrast to
|
||
\fBRemind\fR's concept of "today", which may be changed if it is running
|
||
in calendar mode, or if a date has been supplied on the command line.
|
||
.TP
|
||
.B rows()
|
||
If either standard output or standard error is a TTY, returns the
|
||
height of the terminal in rows. If neither standard output nor
|
||
standard error is a TTY, attempts to open "/dev/tty" to obtain the
|
||
terminal size. If this fails, returns -1.
|
||
.TP
|
||
.B sgn(i_num)
|
||
Returns \-1 if \fInum\fR is negative, 1 if \fInum\fR is positive,
|
||
and 0 if \fInum\fR is zero.
|
||
.TP
|
||
.B shell(s_cmd [,i_maxlen])
|
||
Executes \fIcmd\fR as a system command, and returns the first 511
|
||
characters of output resulting from \fIcmd\fR. Any whitespace
|
||
character in the output is converted to a space. Note that if \fBRUN
|
||
OFF\fR has been executed, or the \fB\-r\fR command-line option has
|
||
been used, \fBshell()\fR will result in an error, and \fIcmd\fR will
|
||
not be executed.
|
||
.RS
|
||
.PP
|
||
When \fBshell\fR runs \fIcmd\fR, it arranges for \fIcmd\fR's standard
|
||
input file descriptor to be connected to /dev/null.
|
||
.PP
|
||
If \fImaxlen\fR is specified, then \fBshell()\fR returns the first
|
||
\fImaxlen\fR characters of output (rather than the first 511). If
|
||
\fImaxlen\fR is specified as a negative number, then it defaults to
|
||
the value of the system variable \fB$MaxStringLen\fR.
|
||
.RE
|
||
.TP
|
||
.B shellescape(s_str)
|
||
Returns \fIstr\fR with all shell metacharacters such as " ", "*", etc
|
||
escaped with a backslash. For example:
|
||
.PP
|
||
.nf
|
||
SET a shellescape("a b*? c&d$e")
|
||
.fi
|
||
.RS
|
||
.PP
|
||
will set \fBa\fR to:
|
||
.RE
|
||
.PP
|
||
.nf
|
||
"a\\ b\\*\\?\\ c\\&d\\$e"
|
||
.fi
|
||
|
||
.TP
|
||
.B slide(d_start, i_amt [, i_step] [,s_wkday...])
|
||
This function is the inverse of \fBnonomitted\fR. It adds \fIamt\fR
|
||
(which can be negative) chunks of \fIstep\fR days to \fIstart\fR,
|
||
\fInot counting omitted days\fR. If \fIstep\fR is not supplied, then
|
||
it is assumed to be 1. Note that only every \fIstep\fRth day is
|
||
tested to see if it is omitted. The optional \fIwkday\fR arguments
|
||
are additional weekday names to omit.
|
||
.RS
|
||
.PP
|
||
Consider this example:
|
||
.PP
|
||
.nf
|
||
OMIT 14 May 2009
|
||
SET a slide('2009-05-13', 5, "Sat", "Sun")
|
||
.fi
|
||
.PP
|
||
In this case, \fIa\fR is set to 2009-05-21. That's because we slide forward
|
||
by 5 days, not including Thursday, May 14 or Saturday and Sunday,
|
||
May 16 and 17. You can go backwards, too, so:
|
||
.PP
|
||
.nf
|
||
OMIT 14 May 2009
|
||
SET a slide('2009-05-21', \-5, "Sat", "Sun")
|
||
.fi
|
||
.PP
|
||
takes \fIa\fR back to 2009-05-13.
|
||
.PP
|
||
Now consider this example:
|
||
.PP
|
||
.nf
|
||
OMIT 14 May 2009
|
||
SET a slide('2009-05-07', 2, 7)
|
||
.fi
|
||
.PP
|
||
This sets \fIa\fR to '2009-05-28' because we skip ahead two weeks, not
|
||
counting a week where the day we land on happens to be omitted. Contrast with
|
||
this:
|
||
.PP
|
||
.nf
|
||
OMIT 13 May 2009
|
||
SET a slide('2009-05-07', 2, 7)
|
||
.fi
|
||
.PP
|
||
which sets \fIa\fR to '2009-05-21'. Although 2009-05-13 is omitted, we
|
||
don't "land" on it as we step forward in chunks of 7 days, so we never
|
||
see that it is omitted.
|
||
.RE
|
||
.TP
|
||
.B soleq(i_which [, dqi_start])
|
||
The \fBsoleq\fR function computes solstices and equinoxes. The \fIwhich\fR
|
||
parameter ranges from 0 to 3, and specifies which event we are interested
|
||
in: 0 is the March equinox; 1 is the June solstice; 2 is the September
|
||
equinox and 3 is the December solstice.
|
||
.RS
|
||
.PP
|
||
The optional \fIstart\fR parameter can either be an integer specifying the
|
||
year of the event we are interested in, or a \fBDATE\fR or \fBDATETIME\fR
|
||
object; if the latter, then \fBsoleq\fR returns the first event on or
|
||
after the date part of the \fIstart\fR parameter (it ignores the time
|
||
component if \fIstart\fR is a \fBDATETIME\fR.) If \fIstart\fR is
|
||
not supplied, then it defaults to \fBtoday()\fR.
|
||
.PP
|
||
The return value of \fBsoleq()\fR is a \fBDATETIME\fR object specifying
|
||
the date and time of the solstice or equinox in the local time zone. It
|
||
should be accurate to within 3 minutes or so in the worst case.
|
||
.PP
|
||
See the included file \fB$SysInclude/seasons.rem\fR for examples of how
|
||
to use \fBsoleq()\fR.
|
||
.RE
|
||
.TP
|
||
.B stdout()
|
||
Returns a string representing where Remind's standard output is going.
|
||
The return values are one of the following: "TTY" if standard-output
|
||
is a terminal, "BLOCKDEV" if it is a block device (very unlikely),
|
||
"CHARDEV" if it is a character device (e.g., /dev/null), "DIR" if it
|
||
is a directory (very unlikely), "PIPE" if it is a pipe or FIFO,
|
||
"SYMLINK" if it is a symlink (very unlikely), "SOCKET" if it is a
|
||
socket, or "UNKNOWN" if it could not be determined.
|
||
.RS
|
||
.PP
|
||
The purpose of \fBstdout()\fR is mostly to distinguish between TTY
|
||
and non-TTY output; you may wish to change or disable colors if the
|
||
output is not going to a TTY.
|
||
.RE
|
||
.TP
|
||
.B strlen(s_str)
|
||
Returns the length of \fIstr\fR in bytes. If the length of \fIstr\fR
|
||
is too large to represent as an integer, emits a "Number too high"
|
||
error. Note that \fBstrlen\fR returns the number of \fIbytes\fR in
|
||
the string, not the number of \fIcharacters\fR. These numbers are the
|
||
same for ASCII strings, but may be different for UTF-8 strings.
|
||
.TP
|
||
.B mbstrlen(str)
|
||
Similar to \fBstrlen\fR, but returns the length of the string in
|
||
\fIcharacters\fR rather than \fIbytes\fR and is thus safe for use
|
||
on multi-byte strings.
|
||
.TP
|
||
.B substr(s_str, i_start [,i_end])
|
||
Returns a \fBSTRING\fR consisting of all bytes in \fIstr\fR from
|
||
\fIstart\fR up to and including \fIend\fR. Bytes are numbered
|
||
from 1. If \fIend\fR is not supplied, then it defaults to the length
|
||
of \fIstr\fR. Because \fBsubstr\fR uses \fIbyte\fR indexes rather than
|
||
\fIcharacter\fR indexes, it should not be used on multi-byte strings.
|
||
.TP
|
||
.B mbsubstr(s_str, i_start [,i_end])
|
||
Similar to \fBsubstr\fR but uses \fIcharacter\fR indexes rather than
|
||
\fIbyte\fR indexes, and is thus safe for use on multi-byte strings.
|
||
.TP
|
||
.B sunrise([dq_date])
|
||
Returns a \fBTIME\fR indicating the time of sunrise on the specified
|
||
\fIdate\fR (default \fBtoday()\fR.) In high latitudes, there
|
||
may be no sunrise on a particular day, in which case \fBsunrise()\fR
|
||
returns the \fBINT\fR 0 if the sun never sets, or 1440 if it never rises.
|
||
.TP
|
||
.B sunset([dq_date])
|
||
Returns a \fBTIME\fR indicating the time of sunset on the specified
|
||
\fIdate\fR (default \fBtoday()\fR.) In high latitudes, there
|
||
may be no sunset on a particular day, in which case \fBsunset()\fR
|
||
returns the \fBINT\fR 0 if the sun never rises, or 1440 if it never
|
||
sets.
|
||
.RS
|
||
.PP
|
||
The functions \fBsunrise()\fR and \fBsunset()\fR are based on
|
||
an algorithm in "Almanac for Computers for the year 1978" by
|
||
L. E. Doggett, Nautical Almanac Office, USNO. They require
|
||
the latitude and longitude to be specified by setting the appropriate
|
||
system variables. (See "System Variables".) The sun functions
|
||
should be accurate to within about 4 minutes for latitudes lower
|
||
than 60 degrees. The functions are available starting from version
|
||
03.00.07 of \fBRemind\fR.
|
||
.RE
|
||
.TP
|
||
.B time(i_hr, i_min)
|
||
Creates a \fBTIME\fR with the hour and minute components specified by
|
||
\fIhr\fR and \fImin\fR.
|
||
.TP
|
||
.B timepart(tq_datetime)
|
||
Returns a \fBTIME\fR object representing the time portion of
|
||
\fIdatetime\fR.
|
||
.TP
|
||
.B timezone([dq_datetime])
|
||
Returns a string representing the local time zone name of the given
|
||
\fBDATETIME\fR. If no argument is supplied, \fBRemind\fR uses the
|
||
value of \fBcurrent()\fR. If a \fBDATE\fR rather than \fBDATETIME\fR
|
||
is supplied, \fBRemind\fR uses a time part of 00:00.
|
||
.TP
|
||
.B today()
|
||
Returns \fBRemind\fR's notion of "today." This may be the actual
|
||
system date, or a date supplied on the command line, or (in Calendar
|
||
Mode) the date of the calendar entry currently being computed.
|
||
.TP
|
||
.B trig(s_1 [,s_2, ...])
|
||
For each string argument s_\fIn\fR, \fBtrig\fR evaluates s_\fIn\fR
|
||
as if it were a REM or IFTRIG trigger
|
||
specification. If the trigger would trigger today, then the trigger
|
||
date is returned and no further triggers are evaluated. If none
|
||
of the triggers would trigger today, then the zero date
|
||
1990-01-01 is returned.
|
||
.RS
|
||
\fBtrig\fR also has a zero-argument form; this returns the trigger
|
||
date of the \fImost recent\fR \fBtrig\fR function that returned a
|
||
non-zero trigger date.
|
||
.PP
|
||
\fBtrig\fR can be used to make more sophisticated versions of
|
||
\fBIFTRIG\fR. For example, if you have meetings every Monday in
|
||
June and July, and you want warnings 3 days in advance, you
|
||
could use:
|
||
.PP
|
||
.nf
|
||
REM [trig("Mon Jun +3", "Mon July +3")] +3 MSG Meeting %b
|
||
.fi
|
||
.PP
|
||
NOTE: We need to repeat the +3 delta outside of the \fBtrig\fR
|
||
function for advance warning to work properly. This is because
|
||
\fBtrig\fR returns a date constant (the trigger date) and the
|
||
REM command does not know the details of \fBtrig\fR's arguments.
|
||
.PP
|
||
Note that because \fBRemind\fR has short-circuit logical
|
||
operators, something like:
|
||
.PP
|
||
.nf
|
||
SET a trig("Mon +7") || trig("Fri +7")
|
||
.fi
|
||
|
||
would set the value of trig() to the date of the following
|
||
Monday. Because trig("Mon +7") always returns true,
|
||
the logical-OR operator does not bother evaluating trig("Fri +7") which
|
||
therefore does not set \fBtrig()\fR.
|
||
.PP
|
||
\fBImportant Note\fR: Because \fBtrig()\fR always returns an absolute
|
||
date, it will \fBnot\fR work properly with a \fBSATISFY\fR clause.
|
||
Consider this reminder:
|
||
.PP
|
||
.nf
|
||
REM [trig("Mar", "Apr")] SATISFY [$Td == 15] MSG 15 Mar or April
|
||
.fi
|
||
.PP
|
||
If we run \fBRemind\fR on 5 March 2022, we might expect the trigger
|
||
date to be calculated as 15 March 2022... but that's not what happens.
|
||
Instead, the \fBtrig\fR function is evaluated first, and it returns
|
||
2022-03-05. So as far as \fBRemind\fR is concerned, the REM statement
|
||
becomes:
|
||
.PP
|
||
.nf
|
||
REM 2022-03-05 SATISFY [$Td == 15] MSG 15 Mar or April
|
||
.fi
|
||
.PP
|
||
and the SATISFY expression is never true. So: \fIDo not mix
|
||
trig() and SATISFY\fR.
|
||
.RE
|
||
.TP
|
||
.B trigdate()
|
||
Returns the calculated trigger date of the last \fBREM\fR
|
||
or \fBIFTRIG\fR command. If used
|
||
in the \fIbody\fR of a \fBREM\fR command, returns that command's trigger date.
|
||
If the most recent \fBREM\fR command did not yield a computable trigger
|
||
date, returns the integer 0.
|
||
.TP
|
||
.B trigdatetime()
|
||
Similar to trigdate(), but returns a \fBDATETIME\fR if the most recent
|
||
triggerable \fBREM\fR command had an \fBAT\fR clause. If there was no
|
||
\fBAT\fR clause, returns a \fBDATE\fR. If no trigger could be computed,
|
||
returns the integer 0. See "MULTI-DAY EVENTS" for more information.
|
||
.TP
|
||
.B trigeventstart()
|
||
Returns a \fBDATETIME\fR representing the start of the most recent
|
||
triggerable \fBREM\fR command that had an \fBAT\fR clause. For events
|
||
without a \fBDURATION\fR or that do not span multiple days, returns
|
||
the same as \fBtrigdatetime()\fR. If the \fBREM\fR command did not
|
||
have an \fBAT\fR clause, returns the integer -1 (and differs from
|
||
\fBtrigdatetime()\fR in this respect.) See "MULTI-DAY EVENTS" for more
|
||
information.
|
||
.TP
|
||
.B trigeventstarttz()
|
||
Similar to \fBtrigeventstart()\fR but returns the DATETIME in the time
|
||
zone specified by a TZ clause, if one was present. If no TZ clause
|
||
was present, returns the same value as \fBtrigeventstart()\fR.
|
||
.TP
|
||
.B trigeventduration()
|
||
Returns a \fBTIME\fR representing the duration of the most recent
|
||
triggerable \fBREM\fR command that had an \fBAT\fR and a
|
||
\fBDURATION\fR clause. If the event does not span multiple days,
|
||
returns the same thing as \fBtrigduration()\fR. If the \fBREM\fR
|
||
command lacked an \fBAT\fR or \fBDURATION\fR clause, returns -1. See
|
||
"MULTI-DAY EVENTS" for more information.
|
||
.TP
|
||
.B trigback()
|
||
Returns the "back" amount of the last \fBREM\fR or \fBIFTRIG\fR command.
|
||
Returns a positive integer N if the "back" is of the form -N, or a negative
|
||
integer if it is of the form --N. If there is no "back", then returns 0.
|
||
.TP
|
||
.B trigbase()
|
||
Returns the "base" date of the last \fBREM\fR or \fBIFTRIG\fR command.
|
||
If the trigger specification includes \fIall three\fR of day, month
|
||
and year, then the base date is the date formed from those components.
|
||
If the trigger specification lacks one of those components, then 0 is
|
||
returned.
|
||
.RS
|
||
.PP
|
||
Here is an example of how \fBtrigbase()\fR might be used:
|
||
.PP
|
||
.nf
|
||
REM 2025-05-05 *7 UNTIL 2025-05-26 \\
|
||
MSG Meeting: week #[(trigdate() - trigbase())/trigrep()+1]
|
||
.fi
|
||
.PP
|
||
On 2025-05-05, it would print: "Meeting: week #1". On 2025-05-12,
|
||
it would print: "Meeting: week #2" and so on.
|
||
.RE
|
||
.TP
|
||
.B trigdelta()
|
||
Returns the "delta" amount of the last \fBREM\fR or \fBIFTRIG\fR command.
|
||
Returns a positive integer N if the "delta" is of the form +N, or a negative
|
||
integer if it is of the form ++N. If there is no "delta", then returns 0.
|
||
.TP
|
||
.B trigtimedelta()
|
||
Similar to \fBtrigdelta()\fR, but returns the delta used in the
|
||
\fBAT\fR clause of a timed reminder.
|
||
.TP
|
||
.B trigrep()
|
||
Returns the "repeat" amount of the last \fBREM\fR or \fBIFTRIG\fR
|
||
command. Returns a positive integer N if the "repeat" is of the form
|
||
*N. If there is no "repeat", then returns 0.
|
||
.TP
|
||
.B trigtimerep()
|
||
Similar to \fBtrigrep()\fR, but returns the repeat used in the \fBAT\fR clause
|
||
of a timed reminder.
|
||
.TP
|
||
.B trigtz()
|
||
If a \fBTZ\fR clause was used in the last \fBREM\fR or \fBIFTRIG\fR
|
||
command, returns the time zone name. Otherwise returns the empty
|
||
string.
|
||
.TP
|
||
.B trigduration()
|
||
Returns (as a TIME type) the \fBDURATION\fR parameter of a timed
|
||
reminder. If there is no \fBDURATION\fR parameter, returns the
|
||
integer -1. See "MULTI-DAY EVENTS" for more information.
|
||
.TP
|
||
.B trigpriority()
|
||
Returns the \fBPRIORITY\fR of the last \fBREM\fR or \fBIFTRIG\fR command.
|
||
.TP
|
||
.B triguntil()
|
||
Returns (as a \fBDATE\fR type) the \fBUNTIL\fR parameter of the last
|
||
\fBREM\fR or \fBIFTRIG\fR command. If there was no \fBUNTIL\fR
|
||
parameter, returns the integer -1. If there is a \fBTHROUGH\fR parameter,
|
||
that will be returned by \fBtriguntil()\fR since "THROUGH yyyy-mm-dd" is simply
|
||
syntactic sugar for "*1 UNTIL yyyy-mm-dd".
|
||
.TP
|
||
.B trigscanfrom()
|
||
Returns (as a \fBDATE\fR type) the \fBSCANFROM\fR parameter of the last \fBREM\fR
|
||
or \fBIFTRIG\fR command. If there was no \fBSCANFROM\fR parameter, returns
|
||
the integer -1. Note that \fBFROM\fR and \fBSCANFROM\fR interact; a reminder that
|
||
has a "FROM yyyy-mm-dd" parameter will act as if it has a \fBSCANFROM\fR parameter
|
||
whose value is the maximum of "yyyy-mm-dd" and today.
|
||
.TP
|
||
.B trigfrom()
|
||
Returns (as a \fBDATE\fR type) the \fBFROM\fR parameter of the last \fBREM\fR or
|
||
\fBIFTRIG\fR command. If there was no \fBFROM\fR parameter, returns the integer -1.
|
||
.TP
|
||
.B triginfo(s_header)
|
||
Returns a \fBSTRING\fR that is the INFO item associated with the header
|
||
\fIheader\fR. The header should \fInot\fR contain a colon. Header name
|
||
comparisons are case-insensitive.
|
||
.RS
|
||
.PP
|
||
For example, the following will assign "At home" to the variable a and
|
||
the empty string to variable b:
|
||
.PP
|
||
.nf
|
||
REM INFO "Location: At home" MSG test
|
||
SET a triginfo("location")
|
||
SET b triginfo("no_such_header")
|
||
.fi
|
||
.PP
|
||
.RE
|
||
.TP
|
||
.B trigistodo()
|
||
Returns 1 if the last \fRREM\fR command was a \fBTODO\fR type or 0 if not.
|
||
.TP
|
||
.B trigcompletethrough()
|
||
Returns a \fBDATE\fR object that is the COMPLETE-THROUGH date of the most
|
||
recent \fBREM\fR command. If there was no COMPLETE-THROUGH date,
|
||
returns the \fBINT\fR 0.
|
||
.TP
|
||
.B trigmaxoverdue()
|
||
Returns an \fBINT\fR that is the MAX-OVERDUE value of the most recent \fBREM\fR
|
||
command. If there was no MAX-OVERDUE clause, returns -1.
|
||
.TP
|
||
.B trigger(d_date [,t_time [,i_utcflag]]) \fRor\fB trigger(q_datetime [,i_utcflag])
|
||
Returns a string suitable for use in a \fBREM\fR command or a
|
||
\fBSCANFROM\fR or UNTIL clause, allowing you to calculate trigger
|
||
dates in advance. Note that in earlier versions of \fBRemind\fR,
|
||
\fBtrigger\fR was required to convert a date into something the
|
||
\fBREM\fR command could consume. However, in this version of
|
||
\fBRemind\fR, you can omit it. Normally, the \fIdate\fR and
|
||
\fItime\fR are the local date and time; however, if \fIutcflag\fR is
|
||
non-zero, the \fIdate\fR and \fItime\fR are interpreted as UTC times,
|
||
and are converted to local time. Examples:
|
||
.RS
|
||
.PP
|
||
trigger('1993/04/01')
|
||
.PP
|
||
returns "1 April 1993",
|
||
.PP
|
||
trigger('1994/08/09', 12:33)
|
||
.PP
|
||
returns "9 August 1994 AT 12:33", as does:
|
||
.PP
|
||
trigger('1994/08/09@12:33').
|
||
.PP
|
||
Finally:
|
||
.PP
|
||
trigger('1994/12/01', 03:00, 1)
|
||
.PP
|
||
returns "30 November 1994 AT 22:00" for EST, which is 5 hours behind UTC.
|
||
The value for your time zone may differ.
|
||
.PP
|
||
\fBtrigger()\fR will \fInever\fR return a date earlier than "1 January 1990"
|
||
even if the UTC flag dictates that it should. So do not use it for reminders
|
||
before about 2 January 1990 in your local time zone. I do not anticipate this
|
||
restriction being a real problem.
|
||
.RE
|
||
.TP
|
||
.B trigtags()
|
||
Returns a comma-separated list of the TAGs associated with the most recent
|
||
\fBREM\fR command that was triggered. Returns the empty string if there
|
||
were no TAGs. If there are multiple tags, they are each separated by
|
||
a single comma, not a comma and a space.
|
||
.TP
|
||
.B trigtime()
|
||
Returns the time of the last \fBREM\fR command with an \fBAT\fR clause
|
||
\fIin the system default time zone\fR. If the last \fBREM\fR did not
|
||
have an \fBAT\fR clause, returns the integer 0. If a \fBREM\fR
|
||
command has an \fBAT\fR clause with a \fBDURATION\fR, then you can
|
||
compute the end time as \fBtrigtime() + trigduration()\fR.
|
||
.TP
|
||
.B trigtimetz()
|
||
Similar to \fBtrigtime()\fR but returns the time in the time zone specified
|
||
by a TZ clause, if one was present. If no TZ clause was present, returns
|
||
the same value as \fBtrigtime()\fR.
|
||
.TP
|
||
.B trigvalid()
|
||
Returns 1 if the value returned by \fBtrigdate()\fR is valid for the most
|
||
recent \fBREM\fR command, or 0 otherwise. Sometimes \fBREM\fR commands
|
||
cannot calculate a trigger date. For example, the following \fBREM\fR
|
||
command can never be triggered:
|
||
.PP
|
||
.nf
|
||
REM Mon OMIT Mon SKIP MSG Impossible!
|
||
.fi
|
||
.PP
|
||
.TP
|
||
.B typeof(x_arg)
|
||
Returns "STRING", "INT", "DATE", "TIME" or "DATETIME", depending on the type of \fIarg\fR.
|
||
.TP
|
||
.B tzconvert(q_datetime, s_srczone [,s_dstzone])
|
||
Converts \fBdatetime\fR from the time zone named by \fBsrczone\fR to
|
||
the time zone named by \fBdstzone\fR. If \fBsrczone\fR is the empty
|
||
string, then the default system time zone is used as the source zone.
|
||
If \fBdstzone\fR is omitted or is the empty string, the default system
|
||
time zone is used as the destination zone. The return value is a
|
||
DATETIME. Time zone names are system-dependent; consult your
|
||
operating system for legal values. Here is an example:
|
||
.RS
|
||
.PP
|
||
.nf
|
||
tzconvert('2007-07-08@01:14', "Canada/Eastern", "Canada/Pacific")
|
||
|
||
returns
|
||
|
||
2007-07-07@22:14
|
||
.fi
|
||
.PP
|
||
If your system includes the directory /usr/share/zoneinfo, \fBRemind\fR
|
||
will warn you if you use an invalid time zone name for \fBsrczone\fR or
|
||
\fBdstzone\fR. To suppress these warnings, add a "!" to the beginning
|
||
of the time zone name.
|
||
.RE
|
||
.PP
|
||
.TP
|
||
.B upper(s_string)
|
||
Returns a \fBSTRING\fR with all lower-case characters in \fIstring\fR
|
||
converted to upper-case.
|
||
.TP
|
||
.B utctolocal(q_datetime)
|
||
Given a \fBDATETIME\fR object interpreted in UTC, return a
|
||
\fBDATETIME\fR object that expresses the same time in the local time
|
||
zone.
|
||
.TP
|
||
.B value(s_varname [,x_default])
|
||
Returns the value of the specified variable. For example, value("X"+"Y")
|
||
returns the value of variable XY, if it is defined. If XY is not defined,
|
||
an error results.
|
||
.RS
|
||
.PP
|
||
However, if you supply a second argument, it is returned if the \fIvarname\fR
|
||
is not defined. The expression value("XY", 0) will return 0 if XY is not
|
||
defined, and the value of XY if it is defined. Note that \fBvalue\fR
|
||
evaluates the second argument lazily; it is \fInot\fR evaluated if
|
||
\fIvarname\fR is defined.
|
||
.RE
|
||
.TP
|
||
.B version()
|
||
Returns a string specifying the version of \fBRemind\fR. For version
|
||
@VERSION@, returns "@VERSION@". It is guaranteed that as new versions of
|
||
\fBRemind\fR are released, the value returned by \fBversion()\fR will
|
||
strictly increase, according to the rules for string ordering.
|
||
.TP
|
||
.B weekno([dq_date, [i_wkstart, [i_daystart]]])
|
||
Returns the week number of the year. If no arguments are supplied,
|
||
returns the ISO 8601 week number for \fBtoday()\fR. If one
|
||
argument \fIdate\fR is supplied, then returns the ISO 8601 week
|
||
number for that date. If two arguments are supplied, then
|
||
\fIwkstart\fR must range from 0 to 6, and represents the first
|
||
day of the week (with 0 being Sunday and 6 being Saturday.). If
|
||
\fIwkstart\fR is not supplied, then it defaults to 1. If the
|
||
third argument \fIdaystart\fR is supplied, then it specifies
|
||
when Week 1 starts. If \fIdaystart\fR is less than or equal to 7,
|
||
then Week 1 starts on the first \fIwkstart\fR on or after
|
||
January \fIdaystart\fR. Otherwise, Week 1 starts on the first
|
||
\fIwkstart\fR on or after December \fIdaystart\fR. If omitted,
|
||
\fIdaystart\fR defaults to 29 (following the ISO 8601 definition.)
|
||
.TP
|
||
.B wkday(dqi_arg)
|
||
If \fIarg\fR is a \fBDATE\fR or \fBDATETIME\fR, returns a string
|
||
representing the day of the week of the date. If \fIarg\fR is an
|
||
\fBINT\fR from 0 to 6, returns the corresponding weekday ("Sunday" to
|
||
"Saturday").
|
||
.TP
|
||
.B wkdaynum(dq_date)\fR or \fBwkdaynum(s_str)\fR
|
||
Returns a number from 0 to 6 representing the day-of-week of the
|
||
specified \fIdate\fR. (0 represents Sunday, and 6 represents
|
||
Saturday.) If a \fBSTRING\fR is supplied, then if \fIstr\fR is a valid
|
||
weekday name (or minimum 3-character abbreviation thereof) then the
|
||
corresponding weekday number is returned. If \fIstr\fR is not a valid
|
||
weekday name, then an error occurs.
|
||
.TP
|
||
.B year(dq_date)
|
||
Returns a \fBINT\fR that is the year component of \fIdate\fR.
|
||
|
||
.SH MACHINES WITH A 32-BIT TIME_T TYPE
|
||
Internally, the standard C library represents times as a \fBtime_t\fR
|
||
type. This is a signed integer type that counts seconds since
|
||
midnight, 1 January 1970 UTC. If the \fBtime_t\fR type is only
|
||
32 bits in size, then the C library cannot represent times after
|
||
19 January 2038 at 03:14:07 UTC.
|
||
.PP
|
||
To work around this limitation, \fBRemind\fR will "fold" years greater than 2037
|
||
to a smaller year that begins on the same day and has the same number of
|
||
days. This results in a year that's very likely to have the same
|
||
daylight saving rules as the original year, unless the rules have changed
|
||
in the interim (in which case the rule change could not even be represented
|
||
on a 32-bit machine, so it's moot.)
|
||
.PP
|
||
\fBRemind\fR then does UTC-to-local or local-to-UTC conversions with the folded
|
||
year, and then post-conversion corrects it back. This should give
|
||
correct results for astronomical functions and conversions between
|
||
local and UTC time, providing the daylight saving time rules have not
|
||
changed between the folded year and the original year.
|
||
.PP
|
||
Note that the $FoldYear system variable is no longer that useful; \fBRemind\fR
|
||
\fIalways\fR folds years if it's necessary on a 32-bit system. You can
|
||
set $FoldYear to 1 to force \fBRemind\fR to fold years even on a 64-bit system,
|
||
but that's useful only for testing and not for production.
|
||
|
||
.SH MULTI-DAY EVENTS
|
||
|
||
If you specify a start time with \fBAT\fR and a duration with
|
||
\fBDURATION\fR, you can create events that span multiple days.
|
||
Consider these two REM statements:
|
||
.PP
|
||
.nf
|
||
REM 1991-02-13 AT 16:00 DURATION 72:00 MSG 72-hour event
|
||
REM 1991-02-13 THROUGH 1991-02-16 AT 16:00 MSG Four events
|
||
.fi
|
||
.PP
|
||
The first statement creates a \fIsingle\fR event that starts on
|
||
13 February 1991 at 16:00 and runs through 16 February 1991 at 16:00
|
||
.PP
|
||
The second statements creates \fIfour separate\fR events that start
|
||
at 16:00 on 13, 14, 15 and 16 February 1991 and have indefinite duration.
|
||
.PP
|
||
\fBRemind\fR handles multi-day events specially. These are the rules:
|
||
.PP
|
||
On the \fIfirst\fR day of a multi-day event, \fBtrigdatetime()\fR will
|
||
return the starting date and time of the event, and \fBtrigduration()\fR
|
||
will return the original DURATION.
|
||
.PP
|
||
On each \fIsubsequent\fR day of a multi-day event, \fBtrigdatetime()\fR
|
||
will return midnight on the day in question, and \fBtrigduration()\fR
|
||
will return the \fIremaining\fR duration. Consider this example:
|
||
.PP
|
||
.nf
|
||
#!/bin/sh
|
||
remind - 12 feb 1991 '*6' <<'EOF'
|
||
BANNER %
|
||
REM 1991-02-13 AT 16:00 DURATION 72:00 SATISFY 1
|
||
set a trigdatetime()
|
||
set b trigduration()
|
||
set c trigeventstart()
|
||
set d trigeventduration()
|
||
MSG now=[today()] dt=[a] dur=[b] estart=[c] edur=[d]%
|
||
EOF
|
||
.fi
|
||
.PP
|
||
The output is:
|
||
.PP
|
||
.nf
|
||
now=1991-02-12 dt=1991-02-13@16:00 dur=72:00 estart=1991-02-13@16:00 edur=72:00
|
||
now=1991-02-13 dt=1991-02-13@16:00 dur=72:00 estart=1991-02-13@16:00 edur=72:00
|
||
now=1991-02-14 dt=1991-02-14@00:00 dur=64:00 estart=1991-02-13@16:00 edur=72:00
|
||
now=1991-02-15 dt=1991-02-15@00:00 dur=40:00 estart=1991-02-13@16:00 edur=72:00
|
||
now=1991-02-16 dt=1991-02-16@00:00 dur=16:00 estart=1991-02-13@16:00 edur=72:00
|
||
now=1991-02-17 dt=1991-02-13@16:00 dur=72:00 estart=-1 edur=-1
|
||
.fi
|
||
.PP
|
||
As you see, the \fBtrigdatetime()\fR and \fBtrigduration()\fR functions
|
||
return the start time and duration of the \fIremaining\fR portion of
|
||
a multi-day event, whereas \fBtrigeventstart\fR and \fBtrigeventduration\fR
|
||
always return the original start and duration of the multi-day event. Note also
|
||
that the return value for expired reminders is not reliable; the fact
|
||
that \fBtrigeventstart\fR and \fBtrigeventduration\fR return -1 in that case
|
||
is an implementation artifact.
|
||
.PP
|
||
.B SELF-OVERLAPPING EVENTS
|
||
.PP
|
||
A multi-day event has the possibility of "overlapping itself". When this
|
||
happens, \fBRemind\fR prefers the \fIlater\fR event (only one copy of
|
||
an event is ever triggered for a given date.) Consider this example:
|
||
.PP
|
||
.nf
|
||
#!/bin/sh
|
||
remind - '*5' 10 Feb 1991 <<'EOF'
|
||
|
||
BANNER %
|
||
REM MON at 0:00 DURATION 192:0 MSG [today()] [trigeventstart()] [trigduration()]%
|
||
|
||
EOF
|
||
.fi
|
||
.PP
|
||
The output is:
|
||
.PP
|
||
.nf
|
||
1991-02-10 1991-02-04@00:00 48:00
|
||
1991-02-11 1991-02-11@00:00 192:00
|
||
1991-02-12 1991-02-11@00:00 168:00
|
||
1991-02-13 1991-02-11@00:00 144:00
|
||
1991-02-14 1991-02-11@00:00 120:00
|
||
.fi
|
||
.PP
|
||
Although the event from 1991-02-04 still has 24 hours left on 1991-02-11,
|
||
the fresh occurrence on 1991-02-11 takes precedences and is the one that
|
||
is triggered.
|
||
.PP
|
||
I do not recommend constructing self-overlapping multi-day events.
|
||
.PP
|
||
.SH EXPRESSION PASTING
|
||
.PP
|
||
An extremely powerful feature of \fBRemind\fR is its macro capability,
|
||
or "expression pasting."
|
||
.PP
|
||
In almost any situation where \fBRemind\fR is not expecting an expression,
|
||
you can "paste" an expression in. To do this, surround the expression
|
||
with square brackets. For example:
|
||
.PP
|
||
.nf
|
||
REM [mydate] MSG foo
|
||
.fi
|
||
.PP
|
||
This evaluates the expression "mydate", where "mydate" is
|
||
presumably some pre-computed variable, and then "pastes" the result
|
||
into the command-line for the parser to process.
|
||
.PP
|
||
If you want a literal "[" character for some reason, simply use "[[". For
|
||
example:
|
||
.PP
|
||
.nf
|
||
REM MSG Here are [[square] brackets!
|
||
.fi
|
||
|
||
.PP
|
||
A formal description of this is: When \fBRemind\fR encounters a
|
||
"pasted-in" expression, it evaluates the expression, and coerces the
|
||
result to a \fBSTRING\fR. It then substitutes the string for the
|
||
pasted-in expression, and continues parsing. Note, however, that
|
||
expressions are evaluated only once, not recursively. Thus, writing:
|
||
.PP
|
||
.nf
|
||
["[a+b]"]
|
||
.fi
|
||
.PP
|
||
causes \fBRemind\fR to read the token "[a+b]". It does not interpret
|
||
this as a pasted-in expression.
|
||
.PP
|
||
You can use expression pasting almost anywhere. However, there are a few
|
||
exceptions:
|
||
.TP
|
||
o
|
||
If \fBRemind\fR is expecting an expression, as in the \fBSET\fR command,
|
||
or the \fBIF\fR command, you should \fBnot\fR include square brackets.
|
||
For example, use:
|
||
.PP
|
||
.nf
|
||
SET a 4+5
|
||
.fi
|
||
and not:
|
||
.nf
|
||
SET a [4+5]
|
||
.fi
|
||
.TP
|
||
o
|
||
You cannot use expression pasting for the first token on a line.
|
||
For example, the following will not work:
|
||
.PP
|
||
.nf
|
||
["SET"] a 1
|
||
.fi
|
||
.RS
|
||
.PP
|
||
This restriction is because \fBRemind\fR must be able to unambiguously
|
||
determine the first token of a line for the flow-control commands (to
|
||
be discussed later.)
|
||
.PP
|
||
In fact, if \fBRemind\fR cannot determine the first token on a line, it
|
||
assumes that it is a \fBREM\fR command. If expression-pasting is used,
|
||
\fBRemind\fR assumes it is a \fBREM\fR command. Thus, the following
|
||
three commands are equivalent:
|
||
.PP
|
||
.nf
|
||
REM 12 Nov 1993 AT 13:05 MSG BOO!
|
||
12 Nov 1993 AT 13:05 MSG BOO!
|
||
[12] ["Nov " + 1993] AT [12:05+60] MSG BOO!
|
||
.fi
|
||
.RE
|
||
.TP
|
||
o
|
||
You cannot use expression-pasting to determine the type (\fBMSG\fR,
|
||
\fBCAL\fR, etc.) of a \fBREM\fR command. You can paste expressions
|
||
before and after the \fBMSG\fR, etc. keywords, but cannot do something like
|
||
this:
|
||
.RS
|
||
.PP
|
||
.nf
|
||
REM ["12 Nov 1993 AT 13:05 " + "MSG" + " BOO!"]
|
||
.fi
|
||
.PP
|
||
However, as an escape hatch, the sequence \fBSPECIAL\fR \fItype\fR
|
||
means the same thing as just \fItype\fR where \fItype\fR is one
|
||
of MSG, MSF, RUN, CAL, PS and PSFILE. This lets you do something
|
||
like this:
|
||
.PP
|
||
.nf
|
||
SET type "MSG"
|
||
REM 12 Nov 2024 SPECIAL [type] Hello
|
||
.fi
|
||
.PP
|
||
You can use this to control the types of your reminders based on variables
|
||
you set, how \fBRemind\fR is invoked, etc.
|
||
.RE
|
||
.PP
|
||
.B COMMON PITFALLS WITH EXPRESSION PASTING
|
||
.PP
|
||
Remember that extra spaces are not inserted when an expression is
|
||
pasted. Thus, something like:
|
||
.PP
|
||
.nf
|
||
REM[expr]MSG[expr]
|
||
.fi
|
||
.PP
|
||
will probably fail.
|
||
.PP
|
||
If you use an expression to calculate a \fIdelta\fR or \fIback\fR,
|
||
ensure that the result is a positive number. Something like:
|
||
.PP
|
||
.nf
|
||
REM +[mydelta] Nov 12 1993 MSG foo
|
||
.fi
|
||
.PP
|
||
will fail if \fImydelta\fR happens to be negative.
|
||
.PP
|
||
.SH FLOW CONTROL COMMANDS
|
||
.PP
|
||
\fBRemind\fR has commands that control the flow of a reminder script.
|
||
Normally, reminder scripts are processed sequentially. However,
|
||
\fBIF\fR and related commands allow you to process files conditionally,
|
||
and skip sections that you don't want interpreted.
|
||
.PP
|
||
.B THE IF COMMAND
|
||
.PP
|
||
The \fBIF\fR command has the following form:
|
||
.PP
|
||
.nf
|
||
IF expr
|
||
t-command
|
||
t-command...
|
||
ELSE
|
||
f-command
|
||
f-command...
|
||
ENDIF
|
||
.fi
|
||
.PP
|
||
Note that the commands are shown indented for clarity. Also, the \fBELSE\fR
|
||
portion can be omitted. \fBIF\fR commands can be nested up to a depth
|
||
of 64, across \fIall\fR levels of INCLUDE.
|
||
.PP
|
||
If the \fIexpr\fR evaluates to a non-zero \fBINT\fR, a \fBDATE\fR that
|
||
is not 1990-01-01, a \fBTIME\fR that is not 00:00, a \fBDATETIME\fR
|
||
that is not 1990-01-01@00:00, or a non-null \fBSTRING\fR, then the
|
||
\fBIF\fR portion is considered true, and the \fIt-commands\fR are
|
||
executed. If \fIexpr\fR evaluates to zero or null, then the
|
||
\fIf-commands\fR (if the \fBELSE\fR portion is present) are executed.
|
||
.PP
|
||
Examples:
|
||
.PP
|
||
.nf
|
||
IF defined("want_hols")
|
||
INCLUDE /usr/share/remind/holidays
|
||
ENDIF
|
||
|
||
IF today() > '1992/2/10'
|
||
set missed_ap "You missed it!"
|
||
ELSE
|
||
set missed_ap "Still have time..."
|
||
ENDIF
|
||
.fi
|
||
.PP
|
||
.B THE IFTRIG COMMAND
|
||
.PP
|
||
The \fBIFTRIG\fR command is similar to an \fBIF\fR command, except
|
||
that it computes a trigger (as in the \fBREM\fR command), and evaluates
|
||
to true if a corresponding \fBREM\fR command would trigger. Examples:
|
||
.PP
|
||
.nf
|
||
IFTRIG 1 Nov
|
||
; Executed on 1 Nov
|
||
ELSE
|
||
; Executed except on 1 Nov
|
||
ENDIF
|
||
|
||
IFTRIG 1 \-1 OMIT Sat Sun +4
|
||
; Executed on last working day of month,
|
||
; and the 4 working days preceding it
|
||
ELSE
|
||
; Executed except on above days
|
||
ENDIF
|
||
.fi
|
||
.PP
|
||
Note that the \fBIFTRIG\fR command computes a trigger date, which can
|
||
be retrieved with the \fBtrigdate()\fR function. You can use all of
|
||
the normal trigger components, such as \fBUNTIL\fR, \fIdelta\fR, etc. in the
|
||
\fBIFTRIG\fR command. However, you cannot use a type specifier such
|
||
as \fBCAL\fR, \fBMSG\fR or \fBSATISFY\fR; attempting to do so
|
||
yields a parse error.
|
||
.PP
|
||
.SH USER-DEFINED FUNCTIONS
|
||
.PP
|
||
In addition to the built-in functions, \fBRemind\fR allows you to define
|
||
your own functions. The \fBFSET\fR command does this for you:
|
||
.PP
|
||
\fBFSET\fR \fIfname\fR(\fIargs\fR) \fIexpr\fR
|
||
.PP
|
||
\fIFname\fR is the name of the function, and follows the convention for
|
||
naming variables. \fIArgs\fR is a comma-separated list of arguments, and
|
||
\fIexpr\fR is an expression. \fIexpr\fR is not evaluated at the time
|
||
the function is defined; instead, it is evaluated each time the function
|
||
is called. \fIArgs\fR can be empty, in which case
|
||
you define a function taking no parameters. Here are some examples:
|
||
.PP
|
||
.nf
|
||
FSET double(x) 2*x
|
||
FSET yeardiff(date1, date2) year(date1) - year(date2)
|
||
FSET since(x) ord($Ty \- x)
|
||
.fi
|
||
.PP
|
||
The last function is useful in birthday reminders. For example:
|
||
.PP
|
||
.nf
|
||
REM 1 Nov +12 MSG Dean's [since(1984)] birthday is %b.
|
||
.fi
|
||
.PP
|
||
Dean was born in 1984. The above example, on 1 November 1992, would print:
|
||
.PP
|
||
.nf
|
||
Dean's 8th birthday is today.
|
||
.fi
|
||
.PP
|
||
Similarly, the function is useful in anniversary reminders. For example:
|
||
.PP
|
||
.nf
|
||
REM 4 June MSG [since(1989)] anniversary of the Tienanmen Square massacre
|
||
.fi
|
||
.PP
|
||
Notes:
|
||
.TP
|
||
o
|
||
If you access a variable in \fIexpr\fR that is not in the list of arguments,
|
||
the global value (if any) is used.
|
||
.TP
|
||
o
|
||
Function and parameter names are significant to 64 characters.
|
||
.TP
|
||
o
|
||
The \fBvalue()\fR function \fIalways\fR accesses the global value of a
|
||
variable, even if it has the same name as an argument. For example:
|
||
.RS
|
||
.PP
|
||
.nf
|
||
fset func(x) value("x")
|
||
set x 1
|
||
set y func(5)
|
||
.fi
|
||
.PP
|
||
The above sequence sets y to 1, which is the global value of x.
|
||
.RE
|
||
.TP
|
||
o
|
||
User-defined functions may call other functions, including other user-defined
|
||
functions. Recursive calls are allowed, but they must terminate (for
|
||
example, by using a short-circuit operator or function that breaks the
|
||
recursion) or an error will result after a certain maximum number of
|
||
recursive calls (by default, 1000.)
|
||
.TP
|
||
o
|
||
If a user-defined function has the same name as a built-in function,
|
||
it is ignored and the built-in function is used. To prevent conflicts
|
||
with future versions of \fBRemind\fR (which may define more built-in
|
||
functions), you may wish to name all user-defined functions beginning
|
||
with an underscore.
|
||
.TP
|
||
o
|
||
If a user-defined function is defined in a context where \fBRUN\fR is
|
||
disabled, then whenever that function is called, \fBRUN\fR will be disabled
|
||
during its evaluation, \fIeven if\fR it is called from a context where
|
||
\fBRUN\fR is enabled.
|
||
|
||
.PP
|
||
To delete a user-defined function, use \fBFUNSET\fR. This takes a
|
||
space-separated list of user-defined functions to delete. For
|
||
example, after the command:
|
||
.PP
|
||
.nf
|
||
FUNSET myfunc1 otherfunc thirdfunc
|
||
.fi
|
||
.PP
|
||
it is guaranteed that no user-defined functions named myfunc1, otherfunc
|
||
or thirdfunc will exist. \fBRemind\fR does not issue an error if you
|
||
try to \fBFUNSET\fR a nonexistent user-defined function; it simply
|
||
does nothing in that case.
|
||
.PP
|
||
You can rename a user-defined function with \fBFRENAME\fR. This takes
|
||
two names: An old name and a new name. Consider this command:
|
||
.PP
|
||
.nf
|
||
FRENAME func_a func_b
|
||
.fi
|
||
.PP
|
||
If \fIfunc_a\fR does not exist, the command unsets \fIfunc_b\fR if
|
||
it is defined. However, if \fIfunc_a\fR exists, then it is renamed to
|
||
\fIfunc_b\fR, and \fIfunc_a\fR is no longer defined. If \fIfunc_b\fR
|
||
was defined prior to the \fBFRENAME\fR command, then that old
|
||
definition is lost.
|
||
.PP
|
||
If either argument to the \fBFRENAME\fR command is the name of a built-in
|
||
function, the command fails with an error message and does nothing.
|
||
.PP
|
||
If you define a user-defined function and then later on redefine it,
|
||
\fBRemind\fR will issue a warning. If you do not want this warning,
|
||
then use \fBFUNSET\fR to remove the existing definition before you
|
||
redefine the function. Alternatively, you can use a "-" token before
|
||
the function name to suppress "redefined function" warnings, as in the
|
||
following example:
|
||
.PP
|
||
.nf
|
||
FSET - f(x) 2*x
|
||
# You must have space before and after the "-"
|
||
# This will NOT work:
|
||
# FSET -f(x) 2*x
|
||
.fi
|
||
.PP
|
||
.SH SAVING AND RESTORING FUNCTIONS
|
||
.PP
|
||
Occasionally, it is useful to redefine a function for a specific block of
|
||
reminders, but to restore its original definition at the end of that
|
||
block. Just as with variables, functions can be pushed onto and popped
|
||
off an internal stack. Here is an example:
|
||
.PP
|
||
.nf
|
||
PUSH-FUNCS msgprefix
|
||
FSET msgprefix(x) "My new prefix: "
|
||
INCLUDE block_of_reminders.rem
|
||
POP-FUNCS
|
||
.fi
|
||
.PP
|
||
The file \fBblock_of_reminders.rem\fR would be executed with the
|
||
\fBmsgprefix\fR function defined above. After the POP-FUNCS
|
||
\fBmsgprefix\fR would be restored to its previous definition if
|
||
it had one, or simply unset if it was not previously defined.
|
||
.PP
|
||
The command PUSH-FUNCS takes a space-separated list of function names.
|
||
All of the named user-defined functions will be saved to an internal
|
||
stack. You can even push names that are not defined as any function.
|
||
.PP
|
||
After a function name has been pushed, \fBRemind\fR will not issue a
|
||
warning if you redefine it, because presumably the purpose of pushing
|
||
it in the first place is to redefine it.
|
||
.PP
|
||
The command POP-FUNCS restores the definitions of all the user-defined
|
||
functions in the corresponding PUSH-FUNCS command. If undefined functions
|
||
were pushed onto the stack, then POP-FUNCS makes those functions undefined
|
||
again. Here's one more example:
|
||
.PP
|
||
.nf
|
||
FUNSET a
|
||
FSET b(x) 2*x
|
||
REM MSG [b(3)] # Outputs 6
|
||
PUSH-FUNCS a b
|
||
FSET a(x) 22*x
|
||
FSET b(x) 3*x
|
||
REM MSG [a(3)] [b(3)] # Outputs 66 9
|
||
POP-FUNCS
|
||
REM MSG [a(3)] # Undefined function "a"
|
||
REM MSG [b(3)] # Outputs 6
|
||
.fi
|
||
.PP
|
||
.SH PRECISE SCHEDULING
|
||
.PP
|
||
The \fBWARN\fR keyword allows precise control over advance warning in
|
||
a more flexible manner than the \fIdelta\fR mechanism. It should be
|
||
followed by the name of a user-defined function, \fIwarn_function\fR.
|
||
.PP
|
||
If a \fIwarn_function\fR is supplied, then it must take one argument of
|
||
type \fBINT\fR. \fBRemind\fR ignores any delta, and instead calls
|
||
\fIwarn_function\fR successively with the arguments 1, 2, 3, ...
|
||
.PP
|
||
\fIWarn_function\fR's return value \fIn\fR is interpreted as follows:
|
||
.TP
|
||
o
|
||
If \fIn\fR is positive, then the reminder is triggered exactly \fIn\fR
|
||
days before its trigger date.
|
||
.TP
|
||
o
|
||
If \fIn\fR is negative, then it is triggered \fIn\fR days before its
|
||
trigger date, \fInot counting\fR \fBOMIT\fRted days.
|
||
.PP
|
||
As an example, suppose you wish to be warned of American Independence Day
|
||
5, 3, and 1 days in advance. You could use this:
|
||
.PP
|
||
.nf
|
||
FSET _wfun(x) choose(x, 5, 3, 1, 0)
|
||
REM 4 July WARN _wfun MSG American Independence Day is %b.
|
||
.fi
|
||
.PP
|
||
.B NOTES
|
||
.TP
|
||
1
|
||
If an error occurs during the evaluation of \fIwarn_function\fR, then
|
||
\fBRemind\fR stops calling it and simply issues the reminder on its
|
||
trigger date.
|
||
.TP
|
||
2
|
||
If the absolute-values of the return values of \fIwarn_function\fR are
|
||
not monotonically decreasing, \fBRemind\fR stops calling it and issues
|
||
the reminder on its trigger date.
|
||
.TP
|
||
3
|
||
\fIWarn_function\fR should (as a matter of good style) return 0 as the
|
||
final value in its sequence of return values. However, a reminder will
|
||
\fIalways\fR be triggered on its trigger date, regardless of what
|
||
\fIwarn_function\fR does.
|
||
.PP
|
||
Similarly to \fBWARN\fR, the \fBSCHED\fR keyword allows precise
|
||
control over the scheduling of timed
|
||
reminders. It should be followed by the name of a user-defined function,
|
||
\fIsched_function\fR.
|
||
.PP
|
||
If a scheduling function is supplied, then it must take one argument of
|
||
type \fBINT\fR. Rather than using the \fBAT\fR time, time \fIdelta\fR, and
|
||
time \fIrepeat\fR, \fBRemind\fR calls the scheduling function to determine
|
||
when to trigger the reminder. The first time the reminder is queued, the
|
||
scheduling function is called with an argument of 1. Each time the reminder
|
||
is triggered, it is re-scheduled by calling the scheduling function again.
|
||
On each call, the argument is incremented by one.
|
||
.PP
|
||
The return value of the scheduling function must be an \fBINT\fR or a
|
||
\fBTIME\fR. If the return value is a \fBTIME\fR, then the reminder is
|
||
re-queued to trigger at that time. If it is a positive integer \fIn\fR,
|
||
then the reminder is re-queued to trigger at the previous trigger time
|
||
plus \fIn\fR minutes. Finally, if it is a negative integer or zero, then
|
||
the reminder is re-queued to trigger \fIn\fR minutes before the \fBAT\fR
|
||
time. Note that there must be an \fBAT\fR clause for the \fBSCHED\fR
|
||
clause to do anything.
|
||
.PP
|
||
Here's an example:
|
||
.PP
|
||
.nf
|
||
FSET _sfun(x) choose(x, \-60, 30, 15, 10, 3, 1, 1, 1, 1, 0)
|
||
REM AT 13:00 SCHED _sfun MSG foo
|
||
.fi
|
||
.PP
|
||
The reminder would first be triggered at 13:00-60 minutes, or at 12:00.
|
||
It would next be triggered 30 minutes later, at 12:30. Then, it would
|
||
be triggered at 12:45, 12:55, 12:58, 12:59, 13:00, 13:01 and 13:02.
|
||
.PP
|
||
.B NOTES
|
||
.TP
|
||
1
|
||
If an error occurs during the evaluation of \fIsched_func\fR, then
|
||
\fBRemind\fR reverts to using the \fBAT\fR time and the \fIdelta\fR
|
||
and \fIrepeat\fR values, and never calls \fIsched_func\fR again.
|
||
.TP
|
||
2
|
||
If processing \fIsched_func\fR yields a time earlier than the current
|
||
system time, it is repeatedly called with increasing argument until it
|
||
yields a value greater than or equal to the current time. However, if
|
||
the sequence of values calculated during the repetition is not strictly
|
||
increasing, then \fBRemind\fR reverts to the default behaviour and
|
||
never calls \fIsched_func\fR again.
|
||
.TP
|
||
3
|
||
It is quite possible using \fIsched_func\fR to keep triggering a reminder
|
||
even after the \fBAT\fR-time. However, it is not possible to reschedule
|
||
a reminder past midnight \- no crossing of date boundaries is allowed.
|
||
Also, it is quite possible to \fBnot\fR trigger a reminder on the \fBAT\fR
|
||
time when you use a scheduling function. However, if your scheduling
|
||
function is terminated (for reasons 1 and 2) before the \fBAT\fR time of
|
||
the reminder, it \fIwill\fR be triggered at the \fBAT\fR time, because
|
||
normal processing takes over.
|
||
.TP
|
||
4
|
||
Your scheduling functions should (as a matter of good style) return
|
||
0 when no more scheduling is required. See the example.
|
||
.TP
|
||
5
|
||
All scheduling functions are evaluated \fIafter\fR the entire Remind
|
||
script has been read in. So whatever function definitions are in effect
|
||
at the end of the script are used.
|
||
.PP
|
||
.SH THE SATISFY CLAUSE
|
||
.PP
|
||
The form of \fBREM\fR that uses \fBSATISFY\fR is as follows:
|
||
.PP
|
||
\fBREM\fR \fItrigger\fR \fBSATISFY\fR \fIexpr\fR
|
||
.PP
|
||
The way this works is as follows: \fBRemind\fR first calculates a trigger
|
||
date, in the normal fashion. Next, it sets \fBtrigdate()\fR to the
|
||
calculated trigger date. It then evaluates \fIexpr\fR. If the result
|
||
is not the null string or zero, processing
|
||
ends. Otherwise, \fBRemind\fR computes the next trigger date, and re-tests
|
||
\fIexpr\fR. This iteration continues until \fIexpr\fR evaluates to non-zero
|
||
or non-null, or until the iteration limit specified with the \fB\-x\fR
|
||
command-line option is reached.
|
||
.PP
|
||
If \fIexpr\fR is not satisfied, then \fBtrigvalid()\fR is set to 0 and
|
||
the error message "Can't compute trigger" is issued. Otherwise,
|
||
\fBtrigvalid()\fR is set to 1.
|
||
.PP
|
||
This is really useful only if \fIexpr\fR involves a call to the
|
||
\fBtrigdate()\fR or related functions or system variables; otherwise,
|
||
\fIexpr\fR will not change as \fBRemind\fR iterates. In fact, if
|
||
\fIexpr\fR is not a constant and does not call \fBtrigdate()\fR or
|
||
related functions or system variables, then \fBRemind\fR will issue a
|
||
warning.
|
||
.PP
|
||
An example of the usefulness of \fBSATISFY\fR: Suppose you wish to
|
||
be warned of every Friday the 13th. Your first attempt may be:
|
||
.PP
|
||
.nf
|
||
# WRONG!
|
||
REM Fri 13 +2 MSG Friday the 13th is %b.
|
||
.fi
|
||
.PP
|
||
But this won't work. This reminder triggers on the first Friday
|
||
on or after the 13th of each month. The way to do it is with a
|
||
more complicated sequence:
|
||
.PP
|
||
.nf
|
||
REM 13 SATISFY wkdaynum(trigdate()) == 5
|
||
IF trigvalid()
|
||
REM [trigdate()] +2 MSG \\
|
||
Friday the 13th is %b.
|
||
ENDIF
|
||
.fi
|
||
.PP
|
||
You can write the REM statement a little more concisely:
|
||
.PP
|
||
.nf
|
||
REM 13 SATISFY $Tw == 5
|
||
.fi
|
||
.PP
|
||
Let's see how this works. The \fBSATISFY\fR clause iterates through
|
||
all the 13ths of successive months, until a trigger date is found whose
|
||
day-of-week is Friday (== 5). If a valid date was found, we use the
|
||
calculated trigger date to set up the next reminder.
|
||
.PP
|
||
We could also have written:
|
||
.PP
|
||
.nf
|
||
REM Fri SATISFY day(trigdate()) == 13
|
||
.fi
|
||
.PP
|
||
but this would result in more iterations, since "Fridays" occur more
|
||
often than "13ths of the month."
|
||
.PP
|
||
Here is another example: Suppose you want to be reminded of something
|
||
on the 15th of January, April, July, and October. You could make
|
||
four separate reminders, or you could use:
|
||
.PP
|
||
.nf
|
||
REM 15 SATISFY [isany($Tm, 1, 4, 7, 10)] MSG 15th Reminder!
|
||
.fi
|
||
.PP
|
||
This technique of using one \fBREM\fR command to calculate a trigger date
|
||
to be used by another command is quite powerful. For example, suppose
|
||
you wanted to OMIT Labour day, which is the first Monday in September. You
|
||
could use:
|
||
.PP
|
||
.nf
|
||
# Note: SATISFY 1 is an idiom for "do nothing"
|
||
REM Mon 1 Sept SATISFY 1
|
||
OMIT [trigdate()]
|
||
.fi
|
||
.PP
|
||
\fBCAVEAT:\fR This \fIonly\fR omits the \fInext\fR Labour Day, not
|
||
all Labour Days in the future. This could cause strange results, as
|
||
the \fBOMIT\fR context can change depending on the current date. For
|
||
example, if you use the following command after the above commands:
|
||
.PP
|
||
.nf
|
||
REM Mon AFTER msg hello
|
||
.fi
|
||
.PP
|
||
the result will not be as you expect. Consider producing a calendar
|
||
for September, 1992. Labour Day was on Monday, 7 September, 1992.
|
||
However, when \fBRemind\fR gets around to calculating the trigger
|
||
for Tuesday, 8 September, 1992, the \fBOMIT\fR command will now be
|
||
omitting Labour Day for 1993, and the "Mon AFTER" command
|
||
will not be triggered. (But see the description of \fBSCANFROM\fR
|
||
in the section "DETAILS ABOUT TRIGGER COMPUTATION.")
|
||
.PP
|
||
It is probably best to stay away from computing \fBOMIT\fR
|
||
trigger dates unless you keep these pitfalls in mind.
|
||
.PP
|
||
For versions of \fBRemind\fR starting from 03.00.07, you can include
|
||
a \fBMSG\fR, \fBRUN\fR, etc. clause in a \fBSATISFY\fR clause as
|
||
follows:
|
||
.PP
|
||
.nf
|
||
REM trigger_stuff SATISFY [expr] MSG body
|
||
.fi
|
||
.PP
|
||
Note that for this case only, the \fIexpr\fR after \fBSATISFY\fR
|
||
\fImust\fR be enclosed in square brackets. It must come after all the other
|
||
components of the trigger, and immediately before the \fBMSG\fR,
|
||
\fBRUN\fR, etc. keyword. If \fIexpr\fR cannot be satisfied, then
|
||
the reminder is not triggered.
|
||
.PP
|
||
Thus, the "Friday the 13th" example can be expressed more compactly as:
|
||
.PP
|
||
.nf
|
||
REM 13 +2 SATISFY [$Tw == 5] MSG Friday the 13th is %b.
|
||
.fi
|
||
.PP
|
||
And you can trigger a reminder on Mondays, Wednesdays and Thursdays
|
||
occurring on odd-numbered days of the month with the following:
|
||
.PP
|
||
.nf
|
||
REM Mon Wed Thu SATISFY [$Td %2 ] MSG Here it is!!!
|
||
.fi
|
||
.PP
|
||
Note that \fBSATISFY\fR and \fBOMITFUNC\fR can often be used to solve the
|
||
same problem, though in different ways. Sometimes a \fBSATISFY\fR is cleaner
|
||
and sometimes an \fBOMITFUNC\fR; experiment and use whichever seems clearer.
|
||
.PP
|
||
.SH POSSIBLY-UNCOMPUTABLE TRIGGERS
|
||
.PP
|
||
Occasionally, you may wish to suppress the "Can't compute trigger" warnings
|
||
for reminders for which a trigger date cannot be computed. For example,
|
||
the following reminder is triggered on a Monday that is not a holiday
|
||
if the following Tuesday is a holiday:
|
||
.PP
|
||
.nf
|
||
REM Mon SKIP SATISFY [isomitted($T+1)] MSG Work between holidays
|
||
.fi
|
||
.PP
|
||
However, if there are no Mondays after today's date that satisfy the
|
||
condition, \fBRemind\fR will print the "Can't compute trigger" error. To
|
||
suppress this, use the \fBMAYBE-UNCOMPUTABLE\fR keyword:
|
||
.PP
|
||
.nf
|
||
REM MAYBE-UNCOMPUTABLE Mon SKIP SATISFY [isomitted($T+1)] MSG Work between holidays
|
||
.fi
|
||
.PP
|
||
It's almost never appropriate to use \fBMAYBE-UNCOMPUTABLE\fR, but it is
|
||
provided for those rare occasions when it makes sense. If you use
|
||
\fBMAYBE-UNCOMPUTABLE\fR inside the \fBevaltrig()\fR function, then
|
||
untriggerable triggers return -1. For example:
|
||
.PP
|
||
.nf
|
||
SET a evaltrig("MAYBE-UNCOMPUTABLE Mon SKIP OMIT Mon")
|
||
.fi
|
||
.PP
|
||
will set a to -1.
|
||
.SH DEBUGGING REMINDER SCRIPTS
|
||
.PP
|
||
Although the command-line \fB\-d\fR option is useful for debugging, it
|
||
is often overkill. For example, if you turn on the \fB\-dx\fR option for
|
||
a reminder file with many complex expressions, you'll get a huge amount of
|
||
output. The \fBDEBUG\fR command allows you to control the debugging flags
|
||
under program control. The format is:
|
||
.PP
|
||
\fBDEBUG\fR [+\fIflagson\fR] [\-\fIflagsoff\fR]
|
||
.PP
|
||
\fIFlagson\fR and \fIflagsoff\fR consist of strings of the characters "shextvlfqnu"
|
||
that correspond to the debugging options discussed in the command-line
|
||
options section. If preceded with a "+", the corresponding group of
|
||
debugging options is switched on. Otherwise, they are switched off.
|
||
For example, you could use this sequence to debug a complicated expression:
|
||
.PP
|
||
.nf
|
||
DEBUG +x
|
||
set a very_complex_expression(many_args)
|
||
DEBUG \-x
|
||
.fi
|
||
.PP
|
||
.B THE DUMPVARS COMMAND
|
||
.PP
|
||
The command \fBDUMPVARS\fR displays the values of variables in memory. Its
|
||
format is:
|
||
.PP
|
||
\fBDUMPVARS\fR [\fB\-c\fR] [\fIvar\fR...]
|
||
.PP
|
||
If you supply a space-separated list of variable names, the corresponding
|
||
variables are displayed. If you do not supply a list of variables, then
|
||
all variables in memory are displayed. To dump a system variable,
|
||
put its name in the list of variables to dump. If you put a lone
|
||
dollar sign in the list of variables to dump, then all system variables
|
||
will be dumped.
|
||
.PP
|
||
If you supply the \fB\-c\fR flag, then any variable determined to be
|
||
constant will have its value followed by "<const>"
|
||
.PP
|
||
.B THE ERRMSG COMMAND
|
||
.PP
|
||
The \fBERRMSG\fR command has the following format:
|
||
.PP
|
||
\fBERRMSG\fR \fIbody\fR
|
||
.PP
|
||
The \fIbody\fR is passed through the substitution filter (with an
|
||
implicit trigger date of \fBtoday()\fR) and printed to the error
|
||
output stream. Example:
|
||
.PP
|
||
.nf
|
||
IF !defined("critical_var")
|
||
ERRMSG You must supply a value for "critical_var"
|
||
EXIT
|
||
ENDIF
|
||
.fi
|
||
.PP
|
||
.B THE EXIT COMMAND
|
||
.PP
|
||
The above example also shows the use of the \fBEXIT\fR command. This
|
||
causes an unconditional exit from script processing. Any queued
|
||
timed reminders are discarded. If you are in calendar mode
|
||
(described next), then the calendar processing is aborted.
|
||
.PP
|
||
If you supply an \fBINT\fR-type expression after the \fBEXIT\fR command,
|
||
it is returned to the calling program as the exit status. Otherwise,
|
||
an exit status of 99 is returned.
|
||
.PP
|
||
.B THE FLUSH COMMAND
|
||
.PP
|
||
This command simply consists of the word \fBFLUSH\fR on a line by
|
||
itself. The command flushes the standard output and standard error
|
||
streams used by \fBRemind\fR. This is not terribly useful to most
|
||
people, but may be useful if you run \fBRemind\fR as a subprocess of
|
||
another program, and want to use pipes for communication.
|
||
.PP
|
||
.SH AGENDA MODE JSON OUTPUT
|
||
.PP
|
||
If you supply the \fB\-\-json\fR argument, then Remind outputs JSON
|
||
instead of the normal text output. The JSON output consists of
|
||
a single JSON array of zero or more objects. There are three
|
||
possible types of objects in the array:
|
||
.TP
|
||
.B banner
|
||
The \fBbanner\fR object, if present, will be the first object in the array.
|
||
There will be at most one \fBbanner\fR object. It contains a single
|
||
key, \fBbanner\fR, whose value is the banner that \fBRemind\fR would normally
|
||
print in Agenda Mode.
|
||
.TP
|
||
.B noreminders
|
||
The \fBnoreminders\fR object, if present, will be the final object in the
|
||
array. There will be at most one \fBnoreminders\fR object. It contains
|
||
a single keym, \fBnoreminders\fR, whose value is the phrase "No reminders.",
|
||
possibly localized into a different language.
|
||
.TP
|
||
.B event
|
||
All other objects in the array are \fBevent\fR objects. They are JSON
|
||
objects that contain all of the keys described in the \fBrem2ps\fR(1)
|
||
man page section "CALENDAR ENTRIES". However, the \fBcalendar_body\fR,
|
||
\fBplain_body\fR and \fBraw_body\fR keys will not be present.
|
||
.PP
|
||
JSON output can be used by a front-end to display an attractive list of
|
||
reminders in Agenda Mode. The "show today's reminders" feature of
|
||
\fBtkremind\fR uses the JSON output.
|
||
.PP
|
||
.SH CALENDAR MODE
|
||
.PP
|
||
If you supply the \fB\-c\fR, \fB\-s\fR or \fB\-p\fR
|
||
command-line option, then \fBRemind\fR
|
||
runs in "calendar mode." In this mode, \fBRemind\fR interprets the script
|
||
repeatedly, performing one iteration through the whole file for each day
|
||
in the calendar. Reminders that trigger are saved in internal buffers,
|
||
and then inserted into the calendar in the appropriate places.
|
||
.PP
|
||
If you also supply the \fB\-a\fR option, then \fBRemind\fR will not
|
||
include timed reminders in the calendar.
|
||
.PP
|
||
The \fB\-p\fR option is used in conjunction with the \fBRem2PS\fR
|
||
program to produce a calendar in PostScript format. For example, the
|
||
following command will send PostScript code to standard output:
|
||
.PP
|
||
.nf
|
||
remind \-p .reminders | rem2ps
|
||
.fi
|
||
.PP
|
||
You can print a PostScript calendar by piping this to the \fBlpr\fR command.
|
||
.PP
|
||
If you have a reminder script called ".reminders", and you
|
||
execute this command:
|
||
.PP
|
||
.nf
|
||
remind \-c .reminders jan 1993
|
||
.fi
|
||
.PP
|
||
then \fBRemind\fR executes the script 31 times, once for each day in
|
||
January. Each time it executes the script, it increments the value
|
||
of \fBtoday()\fR. Any reminders whose trigger date matches \fBtoday()\fR
|
||
are entered into the calendar.
|
||
.PP
|
||
\fBMSG\fR and \fBCAL\fR-type reminders, by default, have their entire
|
||
body inserted into the calendar. \fBRUN\fR-type reminders are not
|
||
normally inserted into the calendar. However, if you enclose a portion of
|
||
the body in the %"...%" sequence, only that portion is inserted. For
|
||
example, consider the following:
|
||
.PP
|
||
.nf
|
||
REM 6 Jan MSG %"Dianne's birthday%" is %b
|
||
.fi
|
||
.PP
|
||
In agenda mode, \fBRemind\fR would print "Dianne's birthday is today"
|
||
on 6 January. However, in the calendar mode, only the text "Dianne's birthday"
|
||
is inserted into the box for 6 January.
|
||
.PP
|
||
If you explicitly use the %"...%" sequence in a \fBRUN\fR-type reminder,
|
||
then the text between the delimiters is inserted into the calendar.
|
||
If you use the sequence %"%" in a \fBMSG\fR or \fBCAL\fR-type reminder, then
|
||
no calendar entry is produced for that reminder.
|
||
.PP
|
||
.B PRESERVING VARIABLES
|
||
.PP
|
||
Because \fBRemind\fR iterates through the script for each day in the calendar,
|
||
slow operations may severely reduce the speed of producing a calendar.
|
||
.PP
|
||
For example, suppose you set the variables "me" and "hostname" as follows:
|
||
.PP
|
||
.nf
|
||
SET me shell("whoami")
|
||
SET hostname shell("hostname")
|
||
.fi
|
||
.PP
|
||
Normally, \fBRemind\fR clears all variables between iterations in calendar
|
||
mode. However, if certain variables are slow to compute, and will
|
||
not change between iterations, you can "preserve" their values with the
|
||
\fBPRESERVE\fR command. Also, since function definitions are preserved
|
||
between calendar iterations, there is no need to redefine them on each
|
||
iteration. Thus, you could use the following sequence:
|
||
.PP
|
||
.nf
|
||
IF ! defined("initialized")
|
||
set initialized 1
|
||
set me shell("whoami")
|
||
set hostname shell("hostname")
|
||
fset func(x) complex_expr
|
||
preserve initialized me hostname
|
||
ENDIF
|
||
.fi
|
||
.PP
|
||
The operation is as follows: On the first iteration through the script,
|
||
"initialized" is not defined. Thus, the commands between \fBIF\fR and
|
||
\fBENDIF\fR are executed. The \fBPRESERVE\fR command ensures that the
|
||
values of initialized, me and hostname are preserved for subsequent
|
||
iterations. On the next iteration, the commands are skipped, since
|
||
initialized has remained defined. Thus, time-consuming operations that
|
||
do not depend on the value of \fBtoday()\fR are done only once.
|
||
.PP
|
||
Most system variables (those whose names start with '$') are automatically
|
||
preserved between calendar iterations.
|
||
.PP
|
||
Note that for efficiency, \fBRemind\fR caches the reminder script
|
||
(and any \fBINCLUDE\fRd files) in memory when producing a calendar.
|
||
.PP
|
||
Timed reminders are sorted and placed into the calendar in time order.
|
||
These are followed by non-timed reminders. \fBRemind\fR automatically
|
||
places the time of timed reminders in the calendar according to the
|
||
\fB\-b\fR command-line option. Reminders in calendar mode are sorted as
|
||
if the \fB\-g\fR option had been used; you can change the sort order
|
||
in calendar mode by explicitly using the \fB\-g\fR option to specify
|
||
a different order from the default.
|
||
.PP
|
||
.B REPEATED EXECUTION
|
||
.PP
|
||
If you supply a \fIrepeat\fR parameter on the command line,
|
||
and do not use the \fB\-c\fR, \fB\-p\fR, or \fB\-s\fR options, \fBRemind\fR
|
||
operates in a similar manner to calendar mode. It repeatedly executes
|
||
the reminder script, incrementing \fBtoday()\fR with each iteration.
|
||
The same rules about preserving variables and function definitions
|
||
apply. Note that using \fIrepeat\fR on the command line also enables
|
||
the \fB\-q\fR option and disables any \fB\-z\fR option.
|
||
As an example, if you want to see how \fBRemind\fR
|
||
will behave for the next week, you can type:
|
||
.PP
|
||
.nf
|
||
remind .reminders '*7'
|
||
.fi
|
||
.PP
|
||
If you want to print the dates of the next 1000 days, use:
|
||
.PP
|
||
.nf
|
||
(echo 'banner %'; echo 'msg [today()]%') | remind - '*1000'
|
||
.fi
|
||
.PP
|
||
.SH INITIALIZING VARIABLES ON THE COMMAND LINE
|
||
.PP
|
||
The \fB\-i\fR option is used to initialize variables on the \fBRemind\fR
|
||
command line. The format is \fB\-i\fR\fIvar\fR\fB=\fR\fIexpr\fR, where
|
||
\fIexpr\fR is any valid expression. Note that you may have to use quotes
|
||
or escapes to prevent the shell from interpreting special characters in
|
||
\fIexpr\fR. You can have as many \fB\-i\fR options as you want on the
|
||
command line, and they are processed in order. Thus, if a variable is defined
|
||
in one \fB\-i\fR option, it can be referred to by subsequent \fB\-i\fR
|
||
options.
|
||
.PP
|
||
Note that if you supply a date on the command line, it is not parsed until
|
||
all options have been processed. Thus, if you use \fBtoday()\fR in any
|
||
of the \fB\-i\fR expressions, it will return the same value as
|
||
\fBrealtoday()\fR and not the date supplied on the command line.
|
||
.PP
|
||
Any variables defined on the command line are \fBpreserved\fR as with the
|
||
\fBPRESERVE\fR command.
|
||
.PP
|
||
You should not have any spaces between the \fB\-i\fR option and the equal
|
||
sign; otherwise, strange variable names are created that can only be accessed
|
||
with the \fBvalue()\fR or \fBdefined()\fR functions.
|
||
.PP
|
||
You can also define a function on the command line by using:
|
||
.PP
|
||
\fB\-i\fR\fIfunc\fR(\fIargs\fR)=\fIdefinition\fR
|
||
.PP
|
||
Be sure to protect special characters from shell interpretation.
|
||
.SH MORE ABOUT POSTSCRIPT
|
||
.PP
|
||
The \fBPS\fR and \fBPSFILE\fR reminders pass PostScript code directly
|
||
to the printer. They differ in that the \fBPS\fR-type reminder passes
|
||
its body directly to the PostScript output (after processing by the
|
||
substitution filter) while the \fBPSFILE\fR-type's body should
|
||
simply consist of a filename. The \fBRem2PS\fR program will open the
|
||
file named in the \fBPSFILE\fR-type reminder, and include its contents in
|
||
the PostScript output.
|
||
.PP
|
||
The PostScript-type reminders for a particular day are included in the
|
||
PostScript output in sorted order of priority. Note that the order
|
||
of PostScript commands has a \fImajor\fR impact on the appearance of the
|
||
calendars. For example, PostScript code to shade a calendar box will
|
||
obliterate code to draw a moon symbol if the moon symbol code is placed
|
||
in the calendar first. For this reason, you should not provide \fBPS\fR
|
||
or \fBPSFILE\fR-type reminders with priorities; instead, you should
|
||
ensure that they appear in the reminder script in the correct order.
|
||
PostScript code should draw objects working from the background to the
|
||
foreground, so that foreground objects properly overlay background ones.
|
||
If you prioritize these reminders and run the script using descending
|
||
sort order for priorities, the PostScript output will not work.
|
||
.PP
|
||
All of the PostScript code for a particular date is enclosed
|
||
in a \fBsave\fR-\fBrestore\fR pair. However, if several PostScript-type
|
||
reminders are triggered for a single day, each section of PostScript is
|
||
not enclosed in a \fBsave\fR-\fBrestore\fR pair - instead, the entire
|
||
body of included PostScript is enclosed.
|
||
.PP
|
||
PostScript-type reminders are executed by the PostScript printer before any
|
||
regular calendar entries. Thus, regular calendar entries will overlay
|
||
the PostScript-type reminders, allowing you to create shaded or graphical
|
||
backgrounds for particular days.
|
||
.PP
|
||
Before executing your PostScript code, the origin of the PostScript coordinate
|
||
system is positioned to the bottom left-hand corner of the "box" in the
|
||
calendar representing \fBtoday()\fR. This location is exactly in the middle
|
||
of the intersection of the bottom and left black lines delineating the box -
|
||
you may have to account for the thickness of these lines when calculating
|
||
positions.
|
||
.PP
|
||
Several PostScript variables are available to the PostScript code you supply.
|
||
All distance and size variables are in PostScript units (1/72 inch.) The
|
||
variables are:
|
||
.TP
|
||
LineWidth
|
||
The width of the black grid lines making up the calendar.
|
||
.TP
|
||
Border
|
||
The border between the center of the grid lines and the space used to print
|
||
calendar entries. This border is normally blank space.
|
||
.TP
|
||
BoxWidth and BoxHeight
|
||
The width and height of the calendar box, from center-to-center of the
|
||
black gridlines.
|
||
.TP
|
||
InBoxHeight
|
||
The height from the center of the bottom black gridline to the top
|
||
of the regular calendar entry area. The space from here to the top
|
||
of the box is used only to draw the day number.
|
||
.TP
|
||
/DayFont, /EntryFont, /SmallFont, /TitleFont and /HeadFont
|
||
The fonts used to draw the day numbers, the calendar entries, the small
|
||
calendars, the calendar title (month, year)
|
||
and the day-of-the-week headings, respectively.
|
||
.TP
|
||
DaySize, EntrySize, TitleSize and HeadSize
|
||
The sizes of the above fonts. (The size of the small calendar font
|
||
is \fInot\fR defined here.) For example, if you wanted to print
|
||
the Hebrew date next to the regular day number in the calendar, use:
|
||
.PP
|
||
.nf
|
||
REM PS Border BoxHeight Border sub DaySize sub moveto \\
|
||
/DayFont findfont DaySize scalefont setfont \\
|
||
([hebday(today())] [hebmon(today())]) show
|
||
.fi
|
||
.PP
|
||
.RS
|
||
Note how /DayFont and DaySize are used.
|
||
.RE
|
||
.PP
|
||
Note that if you supply PostScript code, it is possible to produce invalid
|
||
PostScript files. Always test your PostScript thoroughly with a PostScript
|
||
viewer before sending it to the printer. You should not use any document
|
||
structuring comments in your PostScript code.
|
||
.PP
|
||
.SH DAEMON MODE
|
||
.PP
|
||
If you use the \fB\-z\fR command-line option, \fBRemind\fR runs in
|
||
"daemon mode". In this mode, no "normal" reminders are issued.
|
||
Instead, only timed reminders are collected and queued, and are then
|
||
issued whenever they reach their trigger time.
|
||
.PP
|
||
In addition, \fBRemind\fR wakes up every few minutes to check the
|
||
modification date on the reminder script (the filename supplied on the
|
||
command line.) If \fBRemind\fR detects that the script has changed,
|
||
it re-executes itself in daemon mode, and interprets the changed
|
||
script. If \fBRemind\fR was compiled with support for
|
||
\fBinotify\fR(7), then if the command-line reminder script is really a
|
||
directory, \fBRemind\fR also re-executes itself if any of the files in
|
||
the directory is changed.
|
||
.PP
|
||
In daemon mode, \fBRemind\fR also re-reads the remind script when it
|
||
detects that the system date has changed.
|
||
.PP
|
||
In daemon mode, \fBRemind\fR acts as if the \fB\-f\fR option had been used,
|
||
so to run in daemon mode in the background, use:
|
||
.PP
|
||
.nf
|
||
remind \-z .reminders &
|
||
.fi
|
||
.PP
|
||
If you use \fBsh\fR or \fBbash\fR, you may have to use the "nohup" command
|
||
to ensure that the daemon is not killed when you log out.
|
||
|
||
.PP
|
||
.SH PURGE MODE
|
||
.PP
|
||
|
||
If you supply the \fB\-j\fR command-line option, \fBRemind\fR runs
|
||
in \fIpurge mode\fR. In this mode, it tries to purge expired reminders
|
||
from your reminder files.
|
||
.PP
|
||
In purge mode, \fBRemind\fR reads your reminder file and creates a new
|
||
file by appending ".purged" to the original file name. Note that
|
||
\fBRemind\fR \fInever\fR edits your original file; it always creates
|
||
a new .purged file.
|
||
.PP
|
||
If you invoke \fBRemind\fR against a directory instead of a file, then
|
||
a .purged file is created for each *.rem file in the directory.
|
||
.PP
|
||
Normally, \fBRemind\fR does not create .purged files for INCLUDed files.
|
||
However, if you supply a numeric argument after \fB\-j\fR, then \fBRemind\fR
|
||
will create .purged files for the specified level of INCLUDE. For example,
|
||
if you invoke \fBRemind\fR with the argument \fB\-j2\fR, then .purged
|
||
files will be created for the file (or directory) specified on the command
|
||
line, any files included by them, and any files included by those files.
|
||
However, .purged files will not be created for third-or-higher level
|
||
INCLUDE files.
|
||
.PP
|
||
Determining which reminders have expired is extremely tricky. \fBRemind\fR
|
||
does its best, but you should always compare the .purged file to the
|
||
original file and hand-merge the changes back in.
|
||
.PP
|
||
\fBRemind\fR annotates the .purged file as follows:
|
||
.PP
|
||
An expired reminder is prefixed with: #!P: Expired:
|
||
.PP
|
||
In situations where \fBRemind\fR cannot reliably determine that
|
||
something was expired, you may see the following comments inserted
|
||
before the problematic line:
|
||
.PP
|
||
.nf
|
||
#!P: Cannot purge SATISFY-type reminders
|
||
|
||
#!P: The next IF evaluated false...
|
||
#!P: REM statements in IF block not checked for purging.
|
||
|
||
#!P: The previous IF evaluated true.
|
||
#!P: REM statements in ELSE block not checked for purging
|
||
|
||
#!P: The next IFTRIG did not trigger.
|
||
#!P: REM statements in IFTRIG block not checked for purging.
|
||
|
||
#!P: Next line has expired, but contains expression... please verify
|
||
|
||
#!P: Next line may have expired, but contains non-constant expression
|
||
#!P: or a relative SCANFROM clause
|
||
|
||
#!P! Could not parse next line: Some-Error-Message-Here
|
||
|
||
#!P! Problem calculating trigger date
|
||
.fi
|
||
.PP
|
||
\fBRemind\fR always annotates .purged files with lines beginning with
|
||
"#!P". If such lines are encountered in the \fIoriginal\fR file,
|
||
they are not copied to the .purged file.
|
||
.PP
|
||
If you use the "Hush" flag \fB\-h\fR in conjunction with the "Purge"
|
||
flag \fB\-j\fR, then \fBRemind\fR does \fInot\fR create any
|
||
of the diagnostic comments listed above. Instead, the only change
|
||
it makes to the .purged file is to mark expired reminders with
|
||
"#!P: Expired".
|
||
.PP
|
||
.SH NON-CONSTANT EXPRESSIONS
|
||
.PP
|
||
In Purge Mode, \fBRemind\fR will not mark a REM statement as expired
|
||
if its trigger specification contains a non-constant expression. A
|
||
non-constant expression is defined as one whose value might differ
|
||
from run to run, usually because it depends on the current date, but
|
||
also if it depends on something from the environment (such as the
|
||
output of the \fBshell()\fR function.)
|
||
.PP
|
||
The use of any of the following in an expression causes \fBRemind\fR
|
||
to consider it non-constant:
|
||
.RS
|
||
.TP
|
||
.B o
|
||
A global variable that has been assigned the result of a non-constant
|
||
expression, or that has been assigned a value in a \fInon-constant
|
||
context\fR (to be described later.)
|
||
.TP
|
||
.B o
|
||
A system variable
|
||
.TP
|
||
.B o
|
||
Certain built-in functions that depend on the current date
|
||
(for example, \fBtoday()\fR) or the environment
|
||
(for example, \fBshell()\fR).
|
||
.RE
|
||
.PP
|
||
In addition, for the purposes of safely expiring reminders in Purge
|
||
Mode, \fBRemind\fR considers the following to be non-constant:
|
||
.RS
|
||
.TP
|
||
.B o
|
||
The use of an OMITFUNC
|
||
.TP
|
||
.B o
|
||
The use of a relative SCANFROM
|
||
.RE
|
||
.PP
|
||
Whenever a variable is assigned a value, \fBRemind\fR tracks whether
|
||
or not the expression whose value it was assigned is constant or
|
||
non-constant. Additionally, variables that are assigned in a
|
||
non-constant context are always assumed to be non-constant.
|
||
A non-constant context is the code in the scope of an \fBIF\fR
|
||
statement where the \fBIF\fR expression is non-constant.
|
||
.PP
|
||
Here are some examples that should make things clear:
|
||
.PP
|
||
.nf
|
||
SET d '2025-06-01' # d is constant
|
||
REM [d] MSG Hello! # eligible for purging
|
||
|
||
SET d today() - 3 # d is non-constant
|
||
REM [d] MSG Hello! # not eligible for purging
|
||
|
||
IF wkdaynum(today()) == 3
|
||
set d '2025-06-01' # d is non-constant
|
||
ELSE
|
||
set d '2026-01-01' # d is non-constant
|
||
ENDIF
|
||
|
||
SET d '2025-06-01' # d is constant
|
||
IF today() > today() + 3 # This branch is never taken, but...
|
||
SET d '2029-01-01' # d is still marked non-constant
|
||
ENDIF
|
||
|
||
# Although here d is still '2025-06-01', it is marked
|
||
# non-constant because as far as Remind is concerned,
|
||
# the IF body *might* have been executed depending on today()
|
||
.fi
|
||
.PP
|
||
Note that within the \fBIF\fR...\fBENDIF\fR scope, any assignments
|
||
are non-constant because the code flow depends on today's date, which
|
||
could change in subsequent \fBRemind\fR runs. If you want to force
|
||
a variable to be treated as constant, no matter what, then use the following
|
||
just before you use the variable:
|
||
.PP
|
||
.nf
|
||
SET var const(var)
|
||
.fi
|
||
.PP
|
||
Variables initialized on the command-line with the \fB\-i\fR flag are
|
||
\fIalways\fR considered to be non-constant.
|
||
.PP
|
||
If you have an expired reminder that for some reason you never want
|
||
purged, simply use the built-in function \fBnonconst\fR somewhere in
|
||
the trigger. For example:
|
||
.PP
|
||
.nf
|
||
REM 1992-01-01 MSG This will be purged after Jan 1 1992
|
||
REM [nonconst('1992-01-01')] MSG This will never be purged
|
||
|
||
REM Wed UNTIL 1993-12-31 MSG This will be purged after 1993
|
||
REM Wed UNTIL [nonconst('1993-12-31')] MSG Never purged
|
||
.fi
|
||
.PP
|
||
The \fBn\fR debugging flag prints a message to standard error whenever
|
||
\fBRemind\fR decides that an expression is non-constant. This can produce
|
||
a large amount of output, so if you want to find out why \fBRemind\fR considers
|
||
a specific expression to be non-constant, it's best to use \fBDEBUG +n\fR
|
||
before it and \fBDEBUG -n\fR after it to limit the amount of output.
|
||
.PP
|
||
.SH SORTING REMINDERS
|
||
.PP
|
||
|
||
The \fB\-g\fR option causes \fBRemind\fR to sort reminders by trigger
|
||
date, time and priority before issuing them. Note that reminders are
|
||
still calculated in the order encountered in the script. However,
|
||
rather than being issued immediately, they are saved in an internal
|
||
buffer. When \fBRemind\fR has finished processing the script, it
|
||
issues the saved reminders in sorted order. The \fB\-g\fR option can
|
||
be followed by up to four characters that must all be "a" or "d". The
|
||
first character specifies the sort order by trigger date (ascending or
|
||
descending), the second specifies the sort order by trigger time and
|
||
the third specifies the sort order by priority. If the fourth
|
||
character is "d", the untimed reminders are sorted before timed
|
||
reminders. The default is to sort all fields in ascending order and
|
||
to sort untimed reminders after timed reminders.
|
||
.PP
|
||
In ascending order, reminders are issued with the most imminent first.
|
||
Descending order is the reverse. Reminders are always sorted by
|
||
trigger date, and reminders with the same trigger date are then sorted
|
||
by trigger time. If two reminders have the same date and time, then
|
||
the priority is used to break ties. Reminders with the same date,
|
||
time and priority are issued in the order they were encountered.
|
||
.PP
|
||
You can define a user-defined function called SORTBANNER that takes one
|
||
\fBDATE\fR-type argument. In sort mode, the following sequence happens:
|
||
.PP
|
||
If \fBRemind\fR notices that the next reminder to issue has a different
|
||
trigger date from the previous one (or if it is the first one to be
|
||
issued), then SORTBANNER is called with the trigger date as its argument.
|
||
The result is coerced to a string, and passed through the substitution
|
||
filter with the appropriate trigger date. The result is then displayed.
|
||
.PP
|
||
Here's an example - consider the following fragment:
|
||
.PP
|
||
.nf
|
||
# Switch off the normal banner
|
||
BANNER %
|
||
REM 11 March 1993 ++1 MSG Not so important
|
||
REM 17 March 1993 ++7 MSG Way in the future
|
||
REM 10 March 1993 MSG Important Reminder
|
||
REM 11 March 1993 ++1 MSG Not so important - B
|
||
FSET sortbanner(x) iif(x == today(), \\
|
||
"***** THINGS TO DO TODAY *****", \\
|
||
"----- Things to do %b -----")
|
||
.fi
|
||
.PP
|
||
Running this with the \fB-gaa\fR option on 10 March 1993
|
||
produces the following output:
|
||
.PP
|
||
.nf
|
||
***** THINGS TO DO TODAY *****
|
||
|
||
Important Reminder
|
||
|
||
----- Things to do tomorrow -----
|
||
|
||
Not so important
|
||
|
||
Not so important - B
|
||
|
||
----- Things to do in 7 days' time -----
|
||
|
||
Way in the future
|
||
.fi
|
||
.PP
|
||
You can use the \fBargs()\fR built-in function to determine whether or
|
||
not SORTBANNER has been defined. (This could be used, for example, to
|
||
provide a default definition for SORTBANNER in a system-wide file included
|
||
at the end of the user's file.) Here's an example:
|
||
.PP
|
||
.nf
|
||
# Create a default sortbanner function if it hasn't already
|
||
# been defined
|
||
if args("sortbanner") != 1
|
||
fset sortbanner(x) "--- Things to do %b ---"
|
||
endif
|
||
.fi
|
||
.PP
|
||
.SH MSGPREFIX() AND MSGSUFFIX()
|
||
.PP
|
||
You can define two functions in your script called \fBmsgprefix()\fR
|
||
and \fBmsgsuffix()\fR. They should each accept one argument, a number
|
||
from 0 to 9999.
|
||
.PP
|
||
In agenda mode, for \fBMSG\fR- and \fBMSF\fR-type reminders,
|
||
the following sequence occurs when
|
||
\fBRemind\fR triggers a reminder:
|
||
.TP
|
||
o
|
||
If \fBmsgprefix()\fR is defined, it is evaluated with the priority
|
||
of the reminder as its argument. The result is printed. It is
|
||
\fInot\fR passed through the substitution filter.
|
||
.TP
|
||
o
|
||
The body of the reminder is printed.
|
||
.TP
|
||
o
|
||
If \fBmsgsuffix()\fR is defined, it is evaluated with the priority
|
||
of the reminder as its argument. The result is printed. It is
|
||
\fInot\fR passed through the substitution filter.
|
||
.PP
|
||
Here's an example: The following definition causes priority-0
|
||
reminders to be preceded by "URGENT", and priority-6000 reminders to
|
||
be preceded by "(not important)".
|
||
.PP
|
||
.nf
|
||
fset msgprefix(x) iif(x==0, "URGENT: ", \\
|
||
x==6000, "(not important) ", "")
|
||
.fi
|
||
.PP
|
||
In Calendar Mode (with the \fB\-c\fR, \fB\-s\fR or \fB\-p\fR options),
|
||
an analogous pair of functions named \fBcalprefix()\fR and
|
||
\fBcalsuffix()\fR can be defined. They work with all reminders that
|
||
produce an entry in the calendar (i.e., \fBCAL\fR- and possibly
|
||
\fBRUN\fR-type reminders as well as \fBMSG\fR-type reminders.)
|
||
.PP
|
||
.B NOTES
|
||
.PP
|
||
Normally, the body of a reminder is followed by a carriage return.
|
||
Thus, the results of \fBmsgsuffix()\fR will appear on the next line.
|
||
If you don't want this, make sure the output of \fBmsgsuffix\fR begins
|
||
with a backspace. This places the suffix \fIbefore\fR rather than
|
||
after the carriage return. (The backspace character itself is
|
||
stripped out.) Here is an example:
|
||
.PP
|
||
.nf
|
||
FSET msgsuffix(x) char(8) + " - suffix on same line"
|
||
.fi
|
||
.PP
|
||
.PP
|
||
If \fBRemind\fR has problems evaluating \fBmsgprefix()\fR,
|
||
\fBmsgsuffix()\fR or \fBsortbanner()\fR, you will see a lot of
|
||
error messages. For an example of this, define the following:
|
||
.PP
|
||
.nf
|
||
fset msgprefix(x) x/0
|
||
.fi
|
||
.PP
|
||
.SH COMPILE-TIME SUPPORT FOR OTHER LANGUAGES
|
||
.PP
|
||
\fBRemind\fR used to support compile-time localization to other languages,
|
||
but no longer does. All localization is now done at run-time.
|
||
.PP
|
||
.SH RUN-TIME SUPPORT FOR OTHER LANGUAGES
|
||
.PP
|
||
\fBRemind\fR has run-time support for other languages, and
|
||
compile-time support has been removed in favour of run-time support.
|
||
.PP
|
||
A number of system variables let you translate various phrases
|
||
to other languages. These system variables are:
|
||
.PP
|
||
.TP
|
||
.B $Monday, $Tuesday, $Wednesday, $Thursday, $Friday, $Saturday, $Sunday
|
||
Set each of these system variables to a string representing the corresponding
|
||
day's name in your language. Strings must be valid UTF-8 strings.
|
||
.TP
|
||
.B $January, $February, $March, $April, $May, $June, $July, $August, $September, $October, $November, $December
|
||
Set each of these system variables to a string representing the corresponding
|
||
month's name in your language. Strings must be valid UTF-8 strings.
|
||
.TP
|
||
.B $Ago, $Am, $And, $At, $Hour, $Is, $Minute, $Now, $On, $Pm, $Today, $Tomorrow, $Was
|
||
Set each of these system variables to the translation of the corresponding
|
||
English word into your language. Note that \fB$Am\fR and \fB$Pm\fR should
|
||
be the translations of "AM" and "PM" (morning and afternoon time indicators)
|
||
respectively.
|
||
.TP
|
||
.B $Hplu, $Mplu
|
||
Set these to the suffix to add to the word for "hour" and "minute" to
|
||
make them plural. In English, both would be set to "s".
|
||
.TP
|
||
.B $Fromnow
|
||
Set this to the translation of the English phrase "from now"
|
||
.PP
|
||
Note that if you set any of the language-related system variables,
|
||
they should be set in a section of your script that always is
|
||
evaluated. If you set them inside an \fBIF\fR statement, for example,
|
||
results are unpredictable.
|
||
.PP
|
||
Note also that the \fBRem2PS\fR back-end does not support the full
|
||
range of UTF-8 characters. The \fBTkRemind\fR, \fBrem2html\fR and
|
||
\fBrem2pdf\fR back-ends all do support the full UTF-8 range.
|
||
.PP
|
||
.SH RUN-TIME MODIFICATION OF THE SUBSTITUTION FILTER
|
||
.PP
|
||
The system variables mentioned in the previous section are not typically
|
||
sufficient to properly translate Remind's output to another language.
|
||
Some languages have complicated rules for AM vs PM times and others have
|
||
complex rules for making words plural. \fBRemind\fR therefore allows
|
||
you to define a number of functions that modify the behavior of
|
||
the substitution filter at run-time. The functions are:
|
||
.PP
|
||
.TP
|
||
.B subst_ampm(h)
|
||
This function is passed a single integer, namely an hour from 0 to 23.
|
||
It should return a string that indicates "AM" or "PM" or even finer
|
||
gradations in some languages.
|
||
.TP
|
||
.B subst_ordinal(d)
|
||
This function is passed a single integer, namely a day of the month from
|
||
1 to 31. It should return a string that is suffixed to the day number to
|
||
turn it into an ordinal number. In English, for example, the function
|
||
might return "st", "nd", "rd" or "th", depending on \fId\fR.
|
||
.TP
|
||
.B subst_\fIN\fR\fB(alt, date, time)\fR
|
||
This is actually a \fIfamily\fR of functions, where \fIN\fR is a letter
|
||
or number. This function \fIcompletely overrides\fR the substitution
|
||
sequence "%N". The three arguments are an integer \fIalt\fR which,
|
||
if non-zero, indicates that the alternate-mode substitution sequence
|
||
"%*N" was encountered; \fIdate\fR which is the trigger date of the
|
||
reminder and \fItime\fR which is the trigger time.
|
||
.TP
|
||
.B subst_\fIN\fR\fBx(alt, date, time)\fR
|
||
Again, this is a \fIfamily\fR of functions. It is similar to the
|
||
\fBsubst_\fIN\fR family except it is only called if \fIdate\fR is two or
|
||
more days away from \fItoday()\fR. This is useful if you don't want to
|
||
override the "today" or "tomorrow" output for most substitution sequences.
|
||
.PP
|
||
Here's an example of how you might customize your substitution filter.
|
||
Suppose you want to change the "%b" sequence to substitute "the day
|
||
after tomorrow" for an event two days from now. You could do this:
|
||
.PP
|
||
.nf
|
||
FSET subst_bx(a,d,t) iif(d==today()+2, "the day after tomorrow", \\
|
||
"in " + (d-today()) + " days' time")
|
||
REM [today()+3] ++3 MSG Event 1 is %b%
|
||
REM [today()+2] ++3 MSG Event 2 is %b%
|
||
REM [today()+1] ++3 MSG Event 3 is %b%
|
||
REM [today()] ++3 MSG Event 4 is %b%
|
||
.fi
|
||
.PP
|
||
The output of this script is:
|
||
.PP
|
||
.nf
|
||
Event 1 is in 3 days' time
|
||
Event 2 is the day after tomorrow
|
||
Event 3 is tomorrow
|
||
Event 4 is today
|
||
.fi
|
||
.PP
|
||
Note how Event 2's wording was changed from the normal "in 2 days'
|
||
time", and note also that the "tomorrow" and "today" events used the
|
||
normal substitution---\fBsubst_bx\fR is not called for trigger days of
|
||
today or tomorrow.
|
||
.PP
|
||
As a special case, if a \fBsubst_Nx\fB or \fBsubst_N\fR function
|
||
returns the integer zero, then the normal substitution mechanism is
|
||
used. Therefore, the previous example could have been written more simply
|
||
as:
|
||
.PP
|
||
.nf
|
||
FSET subst_bx(a,d,t) iif(d==today()+2, "the day after tomorrow", 0)
|
||
.fi
|
||
.PP
|
||
You can override substitution sequences that are not alphanumeric as follows:
|
||
.RS
|
||
.PP
|
||
Override %: with \fBsubst_colon\fR
|
||
.PP
|
||
Override %! with \fBsubst_bang\fR
|
||
.PP
|
||
Override %? with \fBsubst_question\fR
|
||
.PP
|
||
Override %@ with \fBsubst_at\fR
|
||
.PP
|
||
Override %# with \fBsubst_hash\fR
|
||
.RE
|
||
.PP
|
||
You can define your own substitution sequences in addition to the built-in
|
||
ones as follows: If you define a function named \fBsubst_\fIname\fB(alt, date, time)\fR, then the sequence \fB%{name}\fR calls the function with \fBalt\fR
|
||
set to 0 and \fBdate\fR and \fBtime\fR to the trigger date and time,
|
||
respectively. The \fB%{name}\fR sequence is replaced with whatever the
|
||
function returns. The sequence \fB%*{name}\fR is similar, but calls
|
||
the function with \fBalt\fR set to 1.
|
||
.PP
|
||
If you use a \fB%{name}\fR sequence and the function \fBsubst_\fIname\fR is
|
||
not defined or returns an error, then \fB%{name}\fR is replaced with the
|
||
empty string.
|
||
.PP
|
||
Note that when \fBRemind\fR invokes any callback function for a
|
||
substitution sequence, \fBRUN\fR will be disabled.
|
||
.PP
|
||
.SH THE TRANSLATION TABLE
|
||
.PP
|
||
To assist with localizing reminder files, \fBRemind\fR maintains a
|
||
table of translations. This is simple a lookup table that maps one
|
||
string (the original string) to a new string (the translated string.)
|
||
When \fBRemind\fR starts executing, the translation table is empty.
|
||
.PP
|
||
To add a message to the translation table, use the \fBTRANSLATE\fR
|
||
command (which may be abbreviated to \fBTRANS\fR.) The \fBTRANSLATE\fR
|
||
command must be followed by two quoted strings, separated from each
|
||
other and from the command by whitespace. For example, a Dutch
|
||
language file might contain something like this:
|
||
.PP
|
||
.nf
|
||
TRANSLATE "New Moon" "Nieuwe maan"
|
||
TRANSLATE "First Quarter" "Eerste kwartier"
|
||
TRANSLATE "Full Moon" "Volle maan"
|
||
TRANSLATE "Last Quarter" "Laatste kwartier"
|
||
.fi
|
||
.PP
|
||
To actually use the translation table, make use of the \fB_\fR built-in
|
||
function, as follows:
|
||
.PP
|
||
.nf
|
||
REM NOQUEUE [moondatetime(0)] MSG [_("New Moon")] (%2)
|
||
REM NOQUEUE [moondatetime(1)] MSG [_("First Quarter")] (%2)
|
||
REM NOQUEUE [moondatetime(2)] MSG [_("Full Moon")] (%2)
|
||
REM NOQUEUE [moondatetime(3)] MSG [_("Last Quarter")] (%2)
|
||
.fi
|
||
.PP
|
||
By using \fBTRANSLATE\fR and \fB_\fR judiciously, you can make your
|
||
reminder files easy to translate.
|
||
.PP
|
||
\fBTRANSLATE\fR has four additional forms: If it is followed
|
||
by \fIone\fR quoted string instead of two, then \fBRemind\fR deletes the
|
||
translation table entry for that string. If it is followed by
|
||
the keyword \fBDUMP\fR, then \fBRemind\fR dumps all translation table entries
|
||
to standard output. And if it is followed by \fBCLEAR\fR, then
|
||
\fBRemind\fR deletes all of the translation table entries.
|
||
.PP
|
||
The fourth form, \fBTRANSLATE GENERATE\fR, dumps all of the
|
||
strings that can be localized (as a series of TRANSLATE commands) to
|
||
standard output. Strings that are already localized are output
|
||
with their localization; strings that are not localized are
|
||
output as:
|
||
.PP
|
||
.nf
|
||
TRANSLATE "untranslated" ""
|
||
.nf
|
||
.PP
|
||
If you want to add a new language, you can obtain a skeleton translation
|
||
file by running:
|
||
.PP
|
||
.nf
|
||
echo "TRANSLATE GENERATE" | remind -h - > /tmp/skeleton.rem
|
||
.fi
|
||
.PP
|
||
If you have an existing language file that is missing some translations,
|
||
you can update it by running:
|
||
.PP
|
||
.nf
|
||
(echo INCLUDE mylang.rem; echo TRANSLATE GENERATE) | \\
|
||
remind -h - > /tmp/mylang-update.rem
|
||
.fi
|
||
.PP
|
||
and then editing \fBmylang-update.rem\fR to add in the missing translations.
|
||
.PP
|
||
If you have some reminder scripts that use the \fB_()\fR built-in function
|
||
or \fB%(...)\fR substitution sequence, you can generate a list of needed
|
||
TRANSLATE commands by running:
|
||
.PP
|
||
.nf
|
||
remind -q -n -dq myscript.rem 2>&1 | grep ^TRANSLATE | sort | uniq
|
||
.fi
|
||
.PP
|
||
Note that if you \fBSET\fR various translation-related system
|
||
variables such as \fB$Monday\fR, \fB$December\fR, \fB$Ago\fR, etc,
|
||
then \fBRemind\fR \fIalso\fR makes a corresponding translation
|
||
table entry automatically. This is done for all of the translation-related
|
||
system variables \fIexcept for\fR \fB$Hplu\fR and \fB$Mplu\fR.
|
||
.PP
|
||
The converse applies too; creating a translation table for
|
||
"December" automatically sets \fB$December\fR. And if you invoke
|
||
\fBTRANSLATE CLEAR\fR, then all translation-related system variables
|
||
are set to their default values as well.
|
||
.PP
|
||
The translation table always contains a special entry \fBLANGID\fR whose
|
||
default value is \fBen\fR. Translators are encouraged to add a \fBLANGID\fR
|
||
entry in their language files; the value should be the two-characters
|
||
ISO 639 language code.
|
||
.PP
|
||
For example, if you write a translation file for the Dutch language,
|
||
add this line:
|
||
.PP
|
||
.nf
|
||
TRANSLATE "LANGID" "nl"
|
||
.fi
|
||
.PP
|
||
Scripts can use \fB_("LANGID")\fR to query the translation language that is
|
||
in effect.
|
||
.PP
|
||
The \fB_()\fR function uses the following procedure to obtain the translation
|
||
for a string:
|
||
.RS
|
||
.TP
|
||
1
|
||
Look for an exact match. If found, return.
|
||
.TP
|
||
2
|
||
If the original string had an upper-case letter, search for the
|
||
all-lower-case equivalent. If found, make the first letter of the
|
||
result upper-case and return.
|
||
.TP
|
||
3
|
||
If the original string started with a lower-case letter, search
|
||
for an equivalent whose first letter is upper-case and the rest lower-case.
|
||
If found, make the first letter of the result lower-case and return.
|
||
.TP
|
||
4
|
||
No translation was found. Return the original string.
|
||
.RE
|
||
.SH LANGUAGE PACKS
|
||
.PP
|
||
\fBRemind\fR ships with a number of language packs, which are simply reminder
|
||
scripts located in \fB[$SysInclude]/lang\fR. The currently-shipping
|
||
language packs are:
|
||
.PP
|
||
da.rem (Danish), de.rem (German), es.rem (Spanish), fr.rem (French),
|
||
is.rem (Icelandic), it.rem (Italian), nl.rem (Dutch), no.rem (Norwegian),
|
||
pl.rem (Polish), pt.rem (Portuguese) and ro.rem (Romanian).
|
||
.PP
|
||
To use a language pack (in this example, de.rem), simply place this at
|
||
the top of your reminders file:
|
||
.PP
|
||
.nf
|
||
SYSINCLUDE lang/de.rem
|
||
.fi
|
||
.PP
|
||
If you want \fBRemind\fR to try to find the language pack appropriate
|
||
for your locale settings, use:
|
||
.PP
|
||
.nf
|
||
SYSINCLUDE lang/auto.rem
|
||
.fi
|
||
.PP
|
||
You are encouraged to study the language packs to see how to translate
|
||
\fBRemind\fR into additional languages.
|
||
.PP
|
||
.SH THE HEBREW CALENDAR
|
||
.PP
|
||
\fBRemind\fR has support for the Hebrew calendar, which is a luni-solar
|
||
calendar. This allows you to create reminders for Jewish holidays,
|
||
jahrzeits (anniversaries of deaths) and smachot (joyous occasions.)
|
||
.PP
|
||
.B THE HEBREW YEAR
|
||
.PP
|
||
The Hebrew year has 12 months, alternately 30 and 29 days long. The
|
||
months are: Tishrey, Heshvan, Kislev, Tevet, Shvat, Adar, Nisan, Iyar,
|
||
Sivan, Tamuz, Av and Elul. If you are in a UTF-8 locale, you can
|
||
\fIalso\fR use the UTF-8-encoded Hebrew spellings for the month names,
|
||
namely:
|
||
.PP
|
||
תשרי, חשוון, כסלו, טבת, שבט, אדר, ניסן, אייר, סיון, תמוז, אב, אלול.
|
||
.PP
|
||
In a cycle of 19 years, there are 7 leap years, being years 3, 6, 8, 11,
|
||
14, 17 and 19 of the cycle. In a leap year, an extra month of 30 days
|
||
is added before Adar. The two Adars are called Adar A and Adar B,
|
||
or in Hebrew, 'אדר א and 'אדר ב.
|
||
.PP
|
||
\fBRemind\fR also permits the following alternative spellings for
|
||
Hebrew month names:
|
||
.TP
|
||
.B Tishrey
|
||
Can also be spelled Tishri or Tishrei
|
||
.TP
|
||
.B Heshvan
|
||
Can also be spelled Cheshvan or Kheshvan
|
||
.TP
|
||
.B Shvat
|
||
Can also be spelled Shevat
|
||
.TP
|
||
.B Tamuz
|
||
Can also be spelled Tammuz
|
||
.TP
|
||
.B Adar A
|
||
Can also be spelled Adar 1, Adar I, אדר א or אדר 1.
|
||
.TP
|
||
.B Adar B
|
||
Can also be spelled Adar 2, Adar II, אדר ב or אדר 2.
|
||
.TP
|
||
.B Iyar
|
||
Can also be spelled Iyyar.
|
||
|
||
.PP
|
||
For certain religious reasons, the year cannot start on a Sunday, Wednesday
|
||
or Friday. To adjust for this, a day is taken off Kislev or added to Heshvan.
|
||
Thus, a regular year can have from 353 to 355 days, and a leap year from
|
||
383 to 385.
|
||
.PP
|
||
When Kislev or Heshvan is short, it is called \fIchaser\fR, or lacking. When
|
||
it is long, it is called \fIshalem\fR, or full.
|
||
.PP
|
||
The Jewish date changes at sunset. However, \fBRemind\fR will change the date
|
||
at midnight, not sunset. So in the period between sunset and midnight,
|
||
\fBRemind\fR will be a day earlier than the true Jewish date. This should not be
|
||
much of a problem in practice.
|
||
.PP
|
||
The computations for the Jewish calendar were based on the program "hdate"
|
||
written by Amos Shapir of the Hebrew University of Jerusalem, Israel. He
|
||
also supplied the preceding explanation of the calendar.
|
||
.PP
|
||
.B HEBREW DATE FUNCTIONS
|
||
.TP
|
||
.B hebday(d_date)
|
||
Returns the day of the Hebrew month corresponding to the \fIdate\fR
|
||
parameter. For example, 12 April 1993 corresponds to 21 Nisan 5753.
|
||
Thus, hebday('1993/04/12') returns 21.
|
||
.TP
|
||
.B hebmon(d_date)
|
||
Returns the name of the Hebrew month corresponding to \fIdate\fR.
|
||
For example, hebmon('1993/04/12') returns "Nisan".
|
||
.TP
|
||
.B ivritmon(d_date)
|
||
Returns the name of the Hebrew month corresponding to \fIdate\fR,
|
||
in UTF-8-encoded Hebrew script. For example, ivritmon('1993/04/12')
|
||
returns "ניסן".
|
||
.TP
|
||
.B hebyear(d_date)
|
||
Returns the Hebrew year corresponding to \fIdate\fR. For example,
|
||
hebyear('1993/04/12') returns 5753.
|
||
.TP
|
||
.B hebdate(i_day, s_hebmon [,id_yrstart [,i_jahr [,i_aflag]]])
|
||
The \fBhebdate()\fR function is the most complex of the Hebrew support
|
||
functions. It can take from 2 to 5 arguments. It returns a \fBDATE\fR
|
||
corresponding to the Hebrew date.
|
||
.PP
|
||
.RS
|
||
The \fIday\fR parameter can range from 1 to 30, and specifies the day of
|
||
the Hebrew month. The \fIhebmon\fR parameter is a string that must name
|
||
one of the Hebrew months specified above. Note that the month must be spelled
|
||
out in full, and use either the English transliteration shown previously, or
|
||
the Hebrew spelling \fIencoded in UTF-8\fR. You can
|
||
also specify "Adar A" and "Adar B." Month names are not case-sensitive.
|
||
.PP
|
||
The \fIyrstart\fR parameter can either be a \fBDATE\fR or an \fBINT\fR. If
|
||
it is a \fBDATE\fR, then the \fBhebdate()\fR scans for the first Hebrew
|
||
date on or after that date. For example:
|
||
.PP
|
||
.nf
|
||
hebdate(15, "Nisan", '1990/01/01')
|
||
.fi
|
||
.PP
|
||
returns 1990/03/30, because that is the first occurrence of 15 Nisan on
|
||
or after 1 January 1990.
|
||
.PP
|
||
If \fIyrstart\fR is an \fBINT\fR, it is interpreted as a Hebrew year. Thus:
|
||
.PP
|
||
.nf
|
||
hebdate(22, "Kislev", 5756)
|
||
.fi
|
||
.PP
|
||
returns 1995/12/15, because that date corresponds to 22 Kislev, 5756. Note
|
||
that none of the Hebrew date functions will work with dates outside
|
||
\fBRemind's\fR normal range for dates.
|
||
.PP
|
||
If \fIyrstart\fR is not supplied, it defaults to \fBtoday()\fR.
|
||
.PP
|
||
The \fIjahr\fR modifies the behaviour of \fBhebdate()\fR as follows:
|
||
.PP
|
||
If \fIjahr\fR is 0 (the default),
|
||
then \fBhebdate()\fR keeps scanning until it
|
||
finds a date that exactly satisfies the other parameters. For example:
|
||
.PP
|
||
.nf
|
||
hebdate(30, "Adar A", 1993/01/01)
|
||
.fi
|
||
.PP
|
||
returns 1995/03/02, corresponding to 30 Adar A, 5755, because that is the
|
||
next occurrence of 30 Adar A after 1 January, 1993. This behaviour is
|
||
appropriate for Purim Katan, which only appears in leap years.
|
||
.PP
|
||
If \fIjahr\fR is 1, then the date is modified as follows:
|
||
.TP
|
||
o
|
||
30 Heshvan is converted to 1 Kislev in years when Heshvan is \fIchaser\fR
|
||
.TP
|
||
o
|
||
30 Kislev is converted to 1 Tevet in years when Kislev is \fIchaser\fR
|
||
.TP
|
||
o
|
||
30 Adar A is converted to 1 Nisan in non-leapyears
|
||
.TP
|
||
o
|
||
Other dates in Adar A are moved to the corresponding day in Adar in
|
||
non-leapyears
|
||
.PP
|
||
This behaviour is appropriate for smachot (joyous occasions) and for
|
||
some jahrzeits - see "JAHRZEITS."
|
||
.PP
|
||
if \fIjahr\fR is 2, then the date is modified as follows:
|
||
.TP
|
||
o
|
||
30 Kislev and 30 Heshvan are converted to 29 Kislev and 29 Heshvan,
|
||
respectively, if the month is \fIchaser\fR
|
||
.TP
|
||
o
|
||
30 Adar A is converted to 30 Shvat in non-leapyears
|
||
.TP
|
||
o
|
||
Other dates in Adar A are moved to the corresponding day in Adar in
|
||
non-leapyears
|
||
.PP
|
||
if \fIjahr\fR is not 0, 1, or 2, it is interpreted as a Hebrew year,
|
||
and the behaviour is calculated as described in the next section,
|
||
"JAHRZEITS."
|
||
.PP
|
||
The \fIaflag\fR parameter modifies the behaviour of the function for
|
||
dates in Adar during leap years. The \fIaflag\fR is \fIonly\fR used
|
||
if \fIyrstart\fR is a \fBDATE\fR type.
|
||
.PP
|
||
The \fIaflag\fR only affects date calculations if \fIhebmon\fR is
|
||
specified as "Adar". In leap years, the following algorithm is followed:
|
||
.TP
|
||
o
|
||
If \fIaflag\fR is 0, then the date is triggered in Adar B. This is
|
||
the default.
|
||
.TP
|
||
o
|
||
If \fIaflag\fR is 1, then the date is triggered in Adar A. This may
|
||
be appropriate for jahrzeits in the Ashkenazi tradition; consult a
|
||
rabbi.
|
||
.TP
|
||
o
|
||
If \fIaflag\fR is 2, then the date is triggered in both Adar A and Adar
|
||
B of a leap year. Some Ashkenazim perform jahrzeit in both Adar A and
|
||
Adar B.
|
||
.RE
|
||
.PP
|
||
.B JAHRZEITS
|
||
.PP
|
||
A jahrzeit is a yearly commemoration of someone's death. It normally takes
|
||
place on the anniversary of the death, but may be delayed if burial is
|
||
delayed - consult a rabbi for more information.
|
||
.PP
|
||
In addition, because some months change length, it is not obvious which day
|
||
the anniversary of a death is. The following rules are used:
|
||
.TP
|
||
o
|
||
If the death occurred on 30 Heshvan, and Heshvan in the year after the
|
||
death is \fIchaser\fR, then the jahrzeit is observed on 29 Heshvan in years
|
||
when Heshvan is \fIchaser\fR. Otherwise, the jahrzeit is observed on 1
|
||
Kislev when Heshvan is \fIchaser\fR.
|
||
.TP
|
||
o
|
||
If the death occurred on 30 Kislev, and Kislev in the year after the
|
||
death is \fIchaser\fR, then the jahrzeit is observed on 29 Kislev in years
|
||
when Kislev is \fIchaser\fR. Otherwise, the jahrzeit is observed on 1
|
||
Tevet when Kislev is \fIchaser\fR.
|
||
.TP
|
||
o
|
||
If the death occurred on 1-29 Adar A, it is observed on 1-29 Adar in
|
||
non-leapyears.
|
||
.TP
|
||
o
|
||
If the death occurred on 30 Adar A, it is observed on 30 Shvat in a
|
||
non-leapyear.
|
||
.PP
|
||
Specifying a Hebrew year for the \fIjahr\fR parameter causes the
|
||
correct behaviour to be selected for a death in that year. You may
|
||
also have to specify \fIaflag\fR, depending on your tradition.
|
||
.PP
|
||
The jahrzeit information was supplied by Frank Yellin, who quoted
|
||
"The Comprehensive Hebrew Calendar" by Arthur Spier, and "Calendrical
|
||
Calculations" by E. M. Reingold and Nachum Dershowitz.
|
||
.PP
|
||
.SH OUT-OF-BAND REMINDERS
|
||
.PP
|
||
The \fBSPECIAL\fR keyword is used to transmit "out-of-band" information
|
||
to \fBRemind\fR backends, such as \fBtkremind\fR or \fBRem2PS\fR.
|
||
They are used only when piping data from a \fBremind \-p\fR line.
|
||
(Note that the COLOR special is an exception; it works similarly
|
||
to MSG when the \fB\-p\fR option is not supplied.)
|
||
.PP
|
||
The various \fBSPECIAL\fRs recognized are particular for each
|
||
backend; however, there are four \fBSPECIAL\fRs that all backends
|
||
should attempt to support. They are currently supported by
|
||
\fBRem2PS\fR, \fBtkremind\fR and \fBrem2html\fR.
|
||
.PP
|
||
The \fBSHADE\fR special replaces the \fBpsshade()\fR function.
|
||
Use it like this:
|
||
.PP
|
||
.nf
|
||
REM Sat Sun SPECIAL SHADE 128
|
||
REM Mon SPECIAL SHADE 255 0 0
|
||
.fi
|
||
.PP
|
||
The \fBSHADE\fR keyword is followed by either one or three numbers,
|
||
from 0 to 255. If one number is supplied, it is interpreted as
|
||
a grey-scale value from black (0) to white (255). If three numbers
|
||
are supplied, they are interpreted as RGB components from minimum (0)
|
||
to maximum (255). The example above shades weekends a fairly dark
|
||
grey and makes Mondays a fully-saturated red. (These shadings appear
|
||
in calendars produced by \fBRem2PS\fR, \fBtkremind\fR and \fBrem2html\fR.)
|
||
.PP
|
||
The \fBMOON\fR special replaces the \fBpsmoon()\fR function. Use it
|
||
like this:
|
||
.PP
|
||
.nf
|
||
REM [moondate(0)] SPECIAL MOON 0
|
||
REM [moondate(1)] SPECIAL MOON 1
|
||
REM [moondate(2)] SPECIAL MOON 2
|
||
REM [moondate(3)] SPECIAL MOON 3
|
||
.fi
|
||
.PP
|
||
These draw little moons on the various calendars. The complete syntax
|
||
of the \fBMOON\fR special is as follows:
|
||
.PP
|
||
.nf
|
||
... SPECIAL MOON phase moonsize fontsize msg
|
||
.fi
|
||
.PP
|
||
\fIPhase\fR is a number from 0 to 3, with 0 representing a new moon,
|
||
1 the first quarter, 2 a full moon and 3 the last quarter.
|
||
.PP
|
||
\fImoonsize\fR is the diameter in PostScript units of the moon to
|
||
draw. If omitted or supplied as \-1, the backend chooses an appropriate
|
||
size.
|
||
.PP
|
||
\fIfontsize\fR is the font size in PostScript units of the \fImsg\fR
|
||
.PP
|
||
\fIMsg\fR is additional text that is placed near the moon glyph.
|
||
.PP
|
||
Note that only the \fBRem2PS\fR backend supports \fImoonsize\fR
|
||
and \fIfontsize\fR; the other backends use fixed sizes.
|
||
.PP
|
||
The \fBCOLOR\fR special lets you place colored reminders in the
|
||
calendar. Use it like this:
|
||
.PP
|
||
.nf
|
||
REM ... SPECIAL COLOR 255 0 0 This is a bright red reminder
|
||
REM ... SPECIAL COLOR 0 128 0 This is a dark green reminder
|
||
.fi
|
||
.PP
|
||
You can spell COLOR either the American way ("COLOR") or the British
|
||
way ("COLOUR"). This manual will use the American way.
|
||
|
||
Immediately following COLOR should be three decimal numbers ranging
|
||
from 0 to 255 specifying red, green and blue intensities, respectively.
|
||
The rest of the line is the text to put in the calendar.
|
||
.PP
|
||
The COLOR special is "doubly special", because in agenda mode,
|
||
\fBremind\fR treats a COLOR special just like a MSG-type reminder.
|
||
Also, if you invoke \fBRemind\fR with \fB\-@\fR[\fIn\fR], then it
|
||
approximates SPECIAL COLOR reminders on your terminal.
|
||
.PP
|
||
See also the documentation of the \fB$DefaultColor\fR system variable
|
||
in the section "SYSTEM VARIABLES".
|
||
.PP
|
||
The \fBWEEK\fR special lets you place annotations such as the week
|
||
number in the calendar. For example, this would number each Monday
|
||
with the ISO 8601 week number. The week number is shown like this:
|
||
"(W\fIn\fR)" in this example, but you can put whatever text you like
|
||
after the WEEK keyword.
|
||
.PP
|
||
.nf
|
||
REM Monday SPECIAL WEEK (W[weekno()])
|
||
.fi
|
||
.PP
|
||
.SH MISCELLANEOUS
|
||
.PP
|
||
.B COMMAND AND KEYWORD ABBREVIATIONS
|
||
.PP
|
||
The following tokens can be abbreviated:
|
||
.TP
|
||
o
|
||
\fBCLEAR-OMIT-CONTEXT\fR --> \fBCLEAR\fR
|
||
.TP
|
||
o
|
||
\fBPUSH-OMIT-CONTEXT\fR --> \fBPUSH\fR
|
||
.TP
|
||
o
|
||
\fBPOP-OMIT-CONTEXT\fR --> \fBPOP\fR
|
||
.TP
|
||
o
|
||
\fBDUMPVARS\fR --> \fBDUMP\fR
|
||
.TP
|
||
o
|
||
\fBBANNER\fR --> \fBBAN\fR
|
||
.TP
|
||
o
|
||
\fBINCLUDE\fR --> \fBINC\fR
|
||
.TP
|
||
o
|
||
\fBMAYBE-UNCOMPUTABLE\fR --> \fBMAYBE\fR
|
||
.TP
|
||
o
|
||
\fBSCANFROM\fR --> \fBSCAN\fR
|
||
.PP
|
||
.B NIFTY EXAMPLES
|
||
.PP
|
||
This section is a sampling of what you can do with \fBRemind\fR.
|
||
.PP
|
||
.nf
|
||
REM 5 Feb 1991 AT 14:00 +45 *30 \\
|
||
RUN mail \-s "Meeting at %2" $LOGNAME </dev/null &
|
||
.fi
|
||
.PP
|
||
On 5 February, 1991, this reminder will mail
|
||
you reminders of a 2:00pm meeting at 1:15,
|
||
1:45 and 2:00. The subject of the mail message will be "Meeting at 2:00pm"
|
||
and the body of the message will be blank.
|
||
.PP
|
||
.nf
|
||
REM AT 17:00 RUN echo "5:00pm - GO HOME!" | xless \-g +0+0 &
|
||
.fi
|
||
.PP
|
||
This reminder will pop up an xless window at 5:00pm every day. The xless
|
||
window will contain the line "5:00pm - GO HOME!"
|
||
.PP
|
||
.nf
|
||
REM AT 23:59 RUN (sleep 120; remind \-a [filename()]) &
|
||
.fi
|
||
.PP
|
||
This reminder will run at one minute to midnight. It will cause a new
|
||
\fBRemind\fR process to start at one minute past midnight. This allows you to
|
||
have a continuous reminder service so you can work through the night and
|
||
still get timed reminders for early in the morning. Note that this
|
||
trick is no longer necessary, providing you run \fBRemind\fR in
|
||
daemon mode.
|
||
.PP
|
||
.nf
|
||
remind \-c12 /dev/null Jan 1993
|
||
.fi
|
||
.PP
|
||
This invocation of \fBRemind\fR will cause it to print a calendar for
|
||
1993, with all entries left blank.
|
||
.PP
|
||
.nf
|
||
REM CAL [trigdate()\-date(year(trigdate()), 1, 1)+1]
|
||
.fi
|
||
.PP
|
||
This example puts an entry in each box of a calendar showing the number
|
||
(1-365 or 366) of the day of the year.
|
||
.PP
|
||
.nf
|
||
REM Tue 2 Nov SATISFY (year(trigdate())%4) == 0
|
||
IF trigvalid()
|
||
REM [trigdate()] ++5 MSG \\
|
||
U.S. Presidential Election!!
|
||
ENDIF
|
||
.fi
|
||
.PP
|
||
This example warns you 5 days ahead of each American presidential
|
||
election. The first \fBREM\fR command calculates the first Tuesday after
|
||
the first Monday in November. (This is equivalent to the first
|
||
Tuesday on or after 2 November.) The \fBSATISFY\fR clause ensures
|
||
that the trigger date is issued only in election years, which are
|
||
multiples of 4. The second \fBREM\fR command actually issues the
|
||
reminder.
|
||
.PP
|
||
.B DETAILS ABOUT TRIGGER COMPUTATION
|
||
.PP
|
||
Here is a \fIconceptual\fR description of how triggers are calculated.
|
||
Note that \fBRemind\fR actually uses a much more efficient procedure,
|
||
but the results are the same as if the conceptual procedure had been
|
||
followed.
|
||
.PP
|
||
\fBRemind\fR starts from the current date (that is, the value of
|
||
\fBtoday()\fR) and scans forward, examining each day one at a time
|
||
until it finds a date that satisfies the trigger, or can prove that
|
||
no such dates (on or later than \fBtoday()\fR) exist.
|
||
.PP
|
||
If \fBRemind\fR is executing a \fBSATISFY\fR-type reminder, it evaluates
|
||
the expression with \fBtrigdate()\fR set to the date found above. If
|
||
the expression evaluates to zero or the null string, \fBRemind\fR continues
|
||
the scanning procedure described above, starting with the day after the
|
||
trigger found above.
|
||
.PP
|
||
The \fBSCANFROM\fR clause (having a syntax similar to \fBUNTIL\fR)
|
||
can modify the search strategy used. In this case, \fBRemind\fR begins the
|
||
scanning procedure at \fIscan_date\fR, which is the date specified in
|
||
the \fBSCANFROM\fR clause. For example:
|
||
.PP
|
||
.nf
|
||
REM Mon 1 SCANFROM 17 Jan 1992 MSG Foo
|
||
.fi
|
||
.PP
|
||
The example above will always have a trigger date of Monday, 3 February 1992.
|
||
That is because \fBRemind\fR starts scanning from 17 January 1992, and
|
||
stops scanning as soon as it hits a date that satisfies "Mon 1."
|
||
.PP
|
||
The main use of \fBSCANFROM\fR is in situations where you want to
|
||
calculate the positions of floating holidays. Consider the Labour
|
||
Day example shown much earlier. Labour Day is the first Monday
|
||
in September. It can move over a range of 7 days. Consider the
|
||
following sequence:
|
||
.PP
|
||
.nf
|
||
REM Mon 1 Sept SCANFROM [today()\-7] ADDOMIT MSG Labour Day
|
||
REM Mon AFTER MSG Hello
|
||
.fi
|
||
.PP
|
||
The \fBSCANFROM\fR clause makes sure that \fBRemind\fR begins scanning
|
||
from 7 days before the current date. This ensures that Labour Day for
|
||
the current year will continue to be triggered until 7 days after it has
|
||
occurred. This allows you to safely use the AFTER keyword as shown.
|
||
.PP
|
||
As a special case, you can simply use a negative number after SCANFROM;
|
||
a negative number \-N is interpreted as N days before today. Thus,
|
||
the previous example could also be written like this:
|
||
.PP
|
||
.nf
|
||
REM Mon 1 Sept SCANFROM \-7 ADDOMIT MSG Labour Day
|
||
REM Mon AFTER MSG Hello
|
||
.fi
|
||
.PP
|
||
A SCANFROM that specifies a full date is called an \fIabsolute SCANFROM\fR
|
||
and a SCANFROM that specifies a negative number is called a
|
||
\fIrelative SCANFROM\fR.
|
||
.PP
|
||
In general, use \fBSCANFROM\fR as shown for safe movable \fBOMITs\fR. The
|
||
amount you should scan back by (7 days in the example above) depends on
|
||
the number of possible consecutive \fBOMITted\fR days that may occur, and
|
||
on the range of the movable holiday. Generally, a value of 7 is safe.
|
||
.PP
|
||
The \fBFROM\fR clause operates almost like the counterpoint to
|
||
\fBUNTIL\fR. It prevents the reminder from triggering before the
|
||
\fBFROM\fR date. For example, the following reminder:
|
||
.PP
|
||
.nf
|
||
REM Mon Thu FROM 23 Jul 2007 UNTIL 2 Aug 2007 MSG Test
|
||
.fi
|
||
.PP
|
||
will trigger on Mondays and Thursdays between 23 July 2007 and
|
||
2 August 2007 inclusive.
|
||
.PP
|
||
\fBFROM\fR is really just syntactic sugar; you could implement
|
||
the reminder above as follows:
|
||
.PP
|
||
.nf
|
||
REM Mon Thu SCANFROM [max(today(), '2007-07-23')] \\
|
||
UNTIL 2 Aug 2007 MSG Test
|
||
.fi
|
||
.PP
|
||
but that's a lot harder to read. Internally, \fBRemind\fR
|
||
treats \fBFROM\fR exactly as illustrated using \fBSCANFROM\fR. For
|
||
that reason, you cannot use both \fBFROM\fR and \fBSCANFROM\fR.
|
||
.PP
|
||
Note that if you use one \fBREM\fR command to calculate a trigger date,
|
||
perform date calculations (addition or subtraction, for example) and
|
||
then use the modified date in a subsequent \fBREM\fR command, the results
|
||
\fImay not be what you intended.\fR This is because you have circumvented
|
||
the normal scanning mechanism. You should try to write \fBREM\fR commands
|
||
that compute trigger dates that can be used unmodified in subsequent
|
||
\fBREM\fR commands. The file "defs.rem" that comes with the \fBRemind\fR
|
||
distribution contains examples.
|
||
.PP
|
||
.B DETAILS ABOUT TRIGVALID()
|
||
.PP
|
||
The \fBtrigvalid()\fR function returns 1 if \fBRemind\fR could find a trigger
|
||
date for the previous \fBREM\fR or \fBIFTRIG\fR command. More specifically,
|
||
it returns 1 if \fBRemind\fR finds a date \fInot before the starting
|
||
date of the scanning\fR that
|
||
satisfies the trigger. In addition, there is one special case in which
|
||
\fBtrigvalid()\fR returns 1 and \fBtrigdate()\fR returns a meaningful result:
|
||
.PP
|
||
If the \fBREM\fR or \fBIFTRIG\fR command did not contain an
|
||
\fBUNTIL\fR or \fBSATISFY\fR clause, and contained all of the
|
||
\fIday\fR, \fImonth\fR and \fIyear\fR components, then \fBRemind\fR
|
||
will correctly compute a trigger date, even if it happens to be before
|
||
the start of scanning. Note that this behaviour is not true for
|
||
versions of \fBRemind\fR prior to 03.00.01.
|
||
|
||
.SH FILES
|
||
.PP
|
||
The traditional location of your reminders file or directory is:
|
||
.PP
|
||
.nf
|
||
$HOME/.reminders
|
||
.fi
|
||
.PP
|
||
where \fB$HOME\fR is your home directory.
|
||
.PP
|
||
\fBRemind\fR ships with some preinstalled files for holidays and language
|
||
packs. These are located in the following directory:
|
||
.PP
|
||
.nf
|
||
@prefix@/share/remind/
|
||
.fi
|
||
.PP
|
||
Do not hard-code the above directory in your reminder files. Instead,
|
||
use the value of the $SysInclude system variable.
|
||
.SH AUTHOR
|
||
.PP
|
||
Dianne Skoll <dianne@skoll.ca> wrote \fBRemind\fR. The moon phase
|
||
code was copied largely unmodified from "moontool" by John Walker.
|
||
The moonrise/moonset code comes from
|
||
https://github.com/signetica/MoonRise by Stephen R. Schmitt and Cyrus
|
||
Rahman. The sunrise and sunset functions use ideas from programs by
|
||
Michael Schwartz and Marc T. Kaufman. The Hebrew calendar support was
|
||
taken from "hdate" by Amos Shapir. The supported languages and
|
||
their translators are listed below. Languages marked "complete"
|
||
support error messages in that language; all others only support the
|
||
substitution filter mechanism and month/day names.
|
||
.PP
|
||
\fBGerman\fR --
|
||
Wolfgang Thronicke
|
||
.PP
|
||
\fBDutch\fR --
|
||
Willem Kasdorp and Erik-Jan Vens
|
||
.PP
|
||
\fBFinnish\fR --
|
||
Mikko Silvonen (complete)
|
||
.PP
|
||
\fBFrench\fR --
|
||
Laurent Duperval (complete)
|
||
.PP
|
||
\fBNorwegian\fR --
|
||
Trygve Randen
|
||
.PP
|
||
\fBDanish\fR --
|
||
Mogens Lynnerup
|
||
.PP
|
||
\fBPolish\fR --
|
||
Jerzy Sobczyk (complete)
|
||
.PP
|
||
\fBBrazilian Portuguese\fR --
|
||
Marco Paganini (complete)
|
||
.PP
|
||
\fBItalian\fR --
|
||
Valerio Aimale
|
||
.PP
|
||
\fBRomanian\fR --
|
||
Liviu Daia
|
||
.PP
|
||
\fBSpanish\fR --
|
||
Rafa Couto
|
||
.PP
|
||
\fBIcelandic\fR --
|
||
Bj\[:o]rn Daví\[Sd]sson
|
||
.SH BUGS
|
||
.PP
|
||
If you find a bug in Remind, please report it to: dianne@skoll.ca
|
||
.PP
|
||
There's no good reason why read-only system variables are not
|
||
implemented as functions, or why functions like \fBversion()\fR, etc.
|
||
are not implemented as read-only system variables.
|
||
.PP
|
||
Hebrew dates in \fBRemind\fR change at midnight instead of sunset.
|
||
.PP
|
||
\fBRemind\fR has some built-in limits (for example, number of global
|
||
\fBOMIT\fRs.)
|
||
.PP
|
||
.SH BIBLIOGRAPHY
|
||
.PP
|
||
Nachum Dershowitz and Edward M. Reingold, "Calendrical Calculations",
|
||
\fISoftware\-Practice and Experience\fR, Vol. 20(9), Sept. 1990,
|
||
pp 899-928.
|
||
.PP
|
||
L. E. Doggett, \fIAlmanac for computers for the year 1978\fR, Nautical
|
||
Almanac Office, USNO.
|
||
.PP
|
||
Richard Siegel and Michael and Sharon Strassfeld, \fIThe First Jewish
|
||
Catalog\fR, Jewish Publication Society of America.
|
||
.PP
|
||
Jean Meeus, \fIAstronomical Algorithms, Second Edition\fR, Willmann-Bell, Inc.
|
||
|
||
.SH HOME PAGE
|
||
https://dianne.skoll.ca/projects/remind/
|
||
.SH MAILING LIST
|
||
https://dianne.skoll.ca/mailman/listinfo/remind-fans
|
||
.SH SEE ALSO
|
||
.PP
|
||
\fBrem\fR(1), \fBrem2ps\fR(1), \fBrem2pdf\fR(1), \fBtkremind\fR(1), \fBrem2html\fR(1)
|
||
|