Expire's operations are controlled by a control file (which can be named or supplied on standard input), which is not optional---there is no default behavior. Each line of the control file should have four white-space-separated fields, as follows.
The first field is one or more newsgroups, separated by commas (no spaces!); partial specifications are acceptable (e.g. `comp' specifies all groups with that prefix).
The second field is one letter, `m', `u', or `x', specifying that the line applies only to moderated groups, only to unmoderated groups, or to both, respectively.
The third field specifies the expiry period in days. The most general form is three numbers separated by dashes. The units are days; decimal fractions are permitted. The first number gives the retention period: how long must pass after an article's arrival before it is a candidate for expiry. The third number gives the purge date: how long must pass after arrival before the article will be expired unconditionally. The middle number gives the default expiry date: how long after an article's arrival it is expired by default. An explicit expiry date in the article will override the default expiry date but not the retention period or the purge date. If the field contains only two numbers with a dash separating them, the retention period defaults to 0. If the field contains only a number, the retention period defaults to 0 and the purge date defaults to `never'. (But see below.)
The fourth field is an archiving directory, or `@' which indicates that the default archiving directory (see -a) should be used, or `-' which suppresses archiving. An explicit archiving directory (not `@') prefixed with `=' means that articles should be archived into that directory itself; normally they go into subdirectories under it by newsgroup name, as in the current-news directory tree. (E.g., article 123 of comp.pc.drivel being archived into archive directory /exp would normally become /exp/comp/pc/drivel/123, but if the archiving directory was given as `=/exp' rather than `/exp', it would become /exp/123.) Expire creates subdirectories under an archiving directory automatically, but will not create the archiving directory itself. Archiving directories must be given as full pathnames.
The first line of the control file which applies to a given article is used to control its expiry. It is an error for no line to apply; the last line should be something like `all x 7 -' to ensure that at least one line is always applicable. Cross-posted articles are treated as if they were independently posted to each group.
The retention and purge defaults can be overridden by including a bounds line, one with the special first field /bounds/; the retention and purge defaults for following lines will be those of the bounds line. The other fields of a bounds line are ignored but must be present.
Entries in the history file can be retained after article expiry, to stop a late-arriving copy of the article from being taken as a new article. To arrange this, include a line with the special first field /expired/; this line then controls the expiry of history lines after the corresponding articles expire. Dates are still measured from article arrival, not expiry. The other fields of such a line are ignored but must be present. It is strongly recommended that such a line be included, and that it specify as long a time as practical.
Command-line options are:
Expire considers the middle field of a history line to consist of one or more subfields separated by `~'. The first is the arrival date, which can be either a getdate(3)-readable date or a decimal seconds count; expire leaves this field unchanged. The second---if present, non-null, and not `-'---is an explicit expiry date for the file, again in either format, which expire will convert to a decimal seconds count as it regenerates the history file. Subsequent fields are preserved but ignored.
Doexpire checks whether another doexpire is running, checks that there is enough disk space for expiry and archiving, invokes expire with any expireoptions given and with /usr/lib/news/explist as the control file, and reports any difficulties by sending mail to usenet. This is usually better than just running expire directly.
Mkhistory rebuilds the history file and its auxiliaries to match the articles in /usr/spool/news. Upact updates the third fields of the active file to match the articles in /usr/spool/news (for historical reasons, expire does not do this). These programs are both fairly slow and they both lock the whole news system for the duration of the run, so they should not be run casually.
Superkludge inspects the files in /usr/spool/news for the newsgroup(s) given, and removes any that have been superseded, according to the `Supersedes' header, by newer ones. The history file is not altered; it's not worth the trouble. The -v option produces a report of how many articles have been superseded in each newsgroup.
/usr/lib/news/historyhistory file /usr/lib/news/history.pagdbm database for history file /usr/lib/news/history.dirdbm database for history file /usr/lib/news/explistexpiry control file /usr/lib/news/history.ohistory file as of last expiry /usr/lib/news/history.n*new history file and dbm files abuilding /usr/lib/news/LOCKexpiredoexpire's lock file /usr/lib/newsbin/expire/*various auxiliaries
The -p subject-finder botches continued header lines, as does mkhistory, although such lines are rare.
Upact and superkludge are distasteful kludges, but then, so are the third field of the active file and the `Supersedes' header.
Some of the more obscure options of expire have not been tested well.
One cannot put more than one newsgroup into a single archiving directory with the `=' feature, since the article numbers will collide with each other and expire doesn't do anything about this.