text.tex

早期freebsd实现

the \MH/ user issues the command:
\example scan\ \bq{pick\ -from\ frated}\endexample
To perform more complicated message selection,
user-defined sequences are employed.
Supplying a \switch{sequence\ name}
argument to \pgm{pick}, will cause it to define the
sequence \arg{name} as those messages matched.

Giving \pgm{pick} a list of messages causes it to limit its search to just
those messages.
For example,
to find all the messages in the current folder from ``frated'' also dated
before friday:
\example pick\ -from\ frated\ -sequence\ select\\
	 pick\ select\ -before\ friday\ -sequence\ select\endexample
With the first \pgm{pick} command,
the sequence \eg{select} is defined
to be all those messages from ``frated''.
In the second command, only those messages already in the \eg{select}
sequence are searched, and the \eg{select} sequence is redefined to be
only those messages which are also
dated before friday.
Those messages could then be \pgm{show\/}n with:
\example show\ select\endexample
When a \switch{sequence\ name} argument is given to \pgm{pick},
the default behavior --- listing the message numbers
matched --- is inhibited.
To re-enable this behavior, the \switch{list} option may be given.
As a result,
advanced users of \MH/ often put the following line in their \profile/:
\example pick:\ -sequence\ select\ -list\endexample
which allows them to easily make use of the \arg{select} sequence as the
messages last selected with \pgm{pick}.

Often it is desirable to act upon those messages which
are {\it not} members of a given sequence.
For this purpose,
the \eg{Sequence-Negation:} profile entry is useful.
If the name of a user-defined sequence is prefixed with the value of the
sequence-negation profile entry,
\MH/ commands will operate upon those messages which are {\it not} members
of that sequence.
For example, given a profile entry of:
\example Sequence-Negation:\ not\endexample
those messages which
are not in the \arg{select} sequence could be \pgm{scan\/}'d with:
\example scan\ notselect\endexample

Obviously, some confusion could result if an attempt was made
to define a sequence name
which began with the sequence-negation string (e.g., \eg{notselect}).
For this reason, \MH/ users will often use a single
character,
which their shell doesn't interpret,
as their sequence-negation string
(e.g., up-caret (`\^{}') for {\it C} Shell users,
and exclamation-mark (`!') for {\it Bourne} shell users).

\MH/ also provides a way of automatically remembering the last
message list given to
an \MH/ command.
This facility is implemented by using a profile entry called
\eg{Previous-Sequence:}.

\subsection{Draft Handling}			% jlr
After the initial edit of a message draft,
the \pgm{comp}, \pgm{dist}, \pgm{forw}, and \pgm{repl} programs
give the user a \whatnow/ prompt.
The valid responses include:
\pgm{edit} to re-edit the draft,
\pgm{quit} to exit without sending the draft,
\pgm{send} to send the draft, and
\pgm{push} to send the draft in the background.

When the \pgm{send} option is given,
the draft is posted with the message transport system.
If there problems posting the draft,
the \whatnow/ prompt is re-issued,
so errors in the draft may be corrected.

Since posting the draft can be slow,
the \pgm{push} option allows the \MH/ user to send the draft in the
background, and return immediately to the shell.
If there are problems posting the message,
the user will not see the diagnostics produced by
the message transport system.
For this reason,
if \pgm{push} is used instead of \pgm{send},
and the message is not successfully posted,
\MH/ mails a message to the user
containing any diagnostics which the message transport system produced
along with a copy of the message.
Later,
the draft may be re-edited by entering \eg{comp\ -use}.

A relatively new feature of \MH/ is the ability to use a folder to store
multiple drafts.
These drafts are kept in an ordinary \MH/ folder,
and may be operated upon by \MH/ commands.
To enable this feature,
the \MH/ user selects a folder-name for the draft-folder,
and creates an entry in the \profile/:
\example Draft-Folder:\ +foldername\endexample
From this point on,
when a message is composed,
the draft will be created as a message in that folder,
instead of using the \file{draft} file in the user's \MH/ directory.
Unfortunately,
if posting problems occur on a message which has been \pgm{push\/}'d,
it may be difficult to re-edit the draft with
\eg{comp\ -use}.
This might be the case if the user had started composing another message,
while that first draft was being posted.
In that event,
the current-message in the draft-folder would no longer point
to the failed draft.

There is a solution for this problem, however.
By default,
\pgm{push} assumes the \switch{forward} option,
which says that if the message draft fails to be posted,
it should be forwarded back to the user in the
error report which \pgm{push} generates.
The failed draft may then be extracted with the \pgm{burst} program
(discussed later).

\subsection{BBoards}				% mtr
\MH/ has a convenient interface to the UCI BBoards facility\cite{MRose84a}.%
\nfootnote{The UCI BBoards facility can run under either the \MMDF/ or
\SendMail/,
or in a more restricted form under stand-alone \MH/.}
This facility permits the efficient distribution of interest group messages
on a single host,
to a group of hosts under a single administration,
and to the ARPA Internet community.

Although most readers are probably familiar with the concept of an interest
group in the Internet context, a brief description is now given.
Observant readers will notice that the distributed nature of the
``network news'' (a.k.a.~USENET)
tends to avoid many of the problems described below.

Described simply, an interest group is composed of a number of subscribers
with a common interest.
These subscribers post mail to a single address, known as the
{\it distribution} address (e.g., {\tx MH-Workers@UCI}.
From this distribution address, a copy of the message is sent to each
subscriber.
Each group has a {\it moderator},
who is the person that runs the group.
This moderator can usually be reached at a special address,
known as the {\it request} address (e.g., {\tx MH-Workers-Request@UCI}).
Usually, the responsibilities of the moderator are quite simple,
since the mail system handles distribution to subscribers automatically.
In some interest groups,
instead of each separate message being distributed directly to subscribers,
a batch of (hopefully related) messages
are put into a {\it digest} format by the
moderator and then sent to the subscribers.
(This is similar to a newsletter format.)
Although this requires more work on the part of the moderator
and introduces delays,
such groups tend to be better organized.

Unfortunately, some problems arise with the scheme outlined above.
First, if two users on the same host subscribe to the same interest group,
two copies of the message are delivered.
This is wasteful of both processor and disk resources at that host.

Second,
some groups carry a lot of traffic.
Although subscription to a group does indicate interest on the part of a
subscriber,
it is usually not interesting to get 50 or so messages delivered
each day
to the user's private maildrop,
interspersed with {\it personal} mail,
which is likely to be of a much more important and timely nature.

Third, if a subscriber's address in a distribution list 
becomes ``bad'' somehow and causes failed mail to be returned,
the originator of the message is normally notified.
It is not uncommon for a large list to have several bogus addresses.
This results in the originator being flooded with ``error messages'' from
mailers across the Internet stating that a given address on the list was
bad.
Needless to say,
the originator usually does not care if the bogus addresses got a copy
of the message or not.
The originator is merely interested in posting a message
to the group at large.
On the other hand,
the moderator of the group does care if there are bogus addresses on the list,
but ironically does not receive notification.

To solve these problems,
the UCI BBoards facility introduces a new entity into the picture:
a {\it distribution channel}.
All interest group mail is handled by 
the special mail system component.
The distribution address for an interest-group
maps mail for that interest-group to the distribution channel,
which then performs
several actions.
First, if local delivery is to be performed,
a copy of the message is placed in a global maildrop for the interest
group with a timestamp and a unique number.
Local users can read messages posted for the interest group by reading this
``public'' maildrop.
Second, if further distribution is to take place,
a copy of the message is sent to the distribution address in such a way that
if any of the addresses are bogus,
failure notices will be returned to the local maintainer of the group
address list, rather than the originator of the message.

This scheme has several advantages:
First, messages delivered to the local host are processed and saved once
in a globally accessible area.
The UCI BBoards facility supports software which allows a user to query an
interest group for new messages and to read and process
those messages in the \MH/-style.
Second, once a host administrator subscribes to an interest group,
each user may join or quit the list's readership without
contacting anyone.
Third, a hierarchical distribution scheme can be constructed to
reduce the amount of delivery effort.
Finally, errors are prevented from propagating.
When an address on the distribution list goes bad,
the list moderator who is responsible for the address is notified.
If a local moderator does not exist,
then the local PostMaster is notified (not the global group moderator).

In addition to solving the problems outlined above,
the UCI BBoards facility supports several other capabilities.
BBoards may be automatically archived in order to conserve disk space and
reduce processing time when reading current items.
Also,
the archives can be separately maintained on tape for access by interested
researchers.

Special alias files may be generated which allow the \MH/ user to shorten
address entry.
For example, instead of sending to {\tx SF-Lovers@Rutgers},
a user of \MH/ usually sends to \eg{SF-Lovers} and the \MH/ aliasing
facility automatically makes the appropriate expansion in the headers of the
outgoing message.
Hence,
the user need only know the name of an interest group and not its global
network address.

Finally, the UCI BBoards facility supports {\it private} interest groups
using the \unix/ group access mechanism.
This allows a group of people on the same or different machines to conduct a
private discussion.

The practical upshot of all this is that the UCI BBoards facility automates
the vast majority of BBoards handling from the point of view of both the
PostMaster and the user.

\MH/ provides three programs to deal with interest groups.
The \pgm{bbc} program is used to check on the status of one or more groups,
and to optionally start an \MH/ shell on those groups which the user is
interested in.
The \pgm{bbl} program can be used to manually perform maintenance on a
discussion group beyond the normal automatic capabilities of the UCI BBoards
facility.
Finally,
the \pgm{msh} program implements an \MH/ shell for reading BBoards,
in which nearly all of the \MH/ commands are implemented in a single program.

Observant readers may note that the use of \pgm{msh} is contrary to the \MH/
philosophy of using relatively small, single-purpose programs.
Sadly,
the authors admit that this is true.
In an effort to minimize use of system resources however,
BBoards are kept in maildrop format instead of folders.%
\nfootnote{When the message transport system delivers a message to a user
it stores it in a single file, called a {\it maildrop}.
Since many messages may be present in a single maildrop,
(in theory) there is a unique string acting as a separator between messages
in the maildrop.