text.tex

早期freebsd实现

The plus-symbol notation is specific to those folders immediately
subordinate to the \Mail/ directory.
This is analogous to ``absolute pathnames'' in \unix/---those
files whose positions in the file system
hierarchy are given starting with the system root,
names prefixed with the slash character (`/').
To specify folders subordinate to the current working folder,
an at-sign (`@') is substituted for (`+').
It is permitted to use \unix/ dot notation to specify parent folders.
Referring to Figure~\MHfiles,
if the current working folder were \eg{+chron/yr.1985},
then the command \example folder\ @../yr.1984\endexample
\noindent
selects the subfolder \file{yr.1984} in the parent directory
\file{chron}, as the new current working folder.
While the current working folder is normally the default, it may be
specified explicitly as \eg{@.}.

\subsection{The Context File}
The \profile/ contains static information about the user's
preferences.
A \context/ file, contained in the \Mail/ directory,
contains the current mail handling environment information,
which changes as different folders, messages, and named message lists
(called {\it message sequences\/})  are selected, created, and updated.
This information is retained between invocations of \MH/ commands,
and is preserved across system sessions.

\tagdiagram{3}{Elaborated Reply Template}{replcomps}
\subsection{Templates}
The message draft composition functions
(\pgm{comp}, \pgm{repl}, \pgm{forw}, and \pgm{dist\/})
use certain default header formats,
which may be changed by the user through the use of message templates.
The exact format of a template may vary among commands.
An example of an elaborated template for the reply command \pgm{repl} is
shown in Figure~\replcomps.

This template specifies how the automatically-generated header for a
draft message in reply to a source message is to be formatted.
The syntax is capable of directing output of header lines based on the
presence or absence of other header lines in the source message.

Other kinds of templates are used to specify the display formats of
messages, or to specify the way that messages are to be included in
other messages.  This is similar to the functionality provided by BBN
Hermes\cite{HERMES},
another powerful mail handling system for \tops20/ based systems.

\subsection{Explaining All This to New Users}
There do exist people who do not like \MH/.%
\nfootnote{At UCI, these
people are reported to be weeded out at an early stage and quietly taken to the
Ministry of Love to be made {\it uncrimethinkful}.}
The emerging pattern of complaints from such people indicates that \MH/
accentuates their perceptions of the deficiencies of \unix/,
to wit, lack of interactivity and lack of easily found help facilities.
Also,
some feel that the proximity of the mail handling environment to the
operating system is a distraction, rather than an asset.
There have been some attempts to make \MH/ more accessible to users who prefer
menu-oriented or monolithic mail system interfaces.%
\nfootnote{For example,
\pgm{mhe} from Brian Reid of Stanford University
and \pgm{emh} from Marshall Rose
are instances of macro packages for James Gosling's \EMACS/ extensible editor,
while the \pgm{hm} program from Jim Guyton of the Rand Corporation is a
monolithic \MH/ interface.
As of this writing,
none of these programs is documented in the literature.}

In truth,
users new to \unix/ do not always acclimate to \MH/ easily.
The command set is undistinguishably mixed in with all other \unix/
utilities, and it is not easy, without aid of a manual,
to pick out the necessary commands.
\MH/ does not provide any ``hand-holding'' to guide
the user through a minimally useful command subset.

Another problem is that the initial default user profile is too often sparse,
containing only a \eg{Path:} parameter.
\MH/ commands will perform adequately without specific information
in the profile,
so new users often neglect optionally useful \MH/ capabilities,
eventually becoming frustrated with the limited default capabilities,
yet unable to determine without researching through the user's manual,
the necessary options that would solve their problems.

The currently available means for learning how to use \MH/ are:
\medskip
{\advance\leftskip by 2\parindent
\item{$\bullet$}
One-on-one tutoring by knowledgeable \MH/ users,
which has so far shown the best results with new users.

\item{$\bullet$}
Consulting the {\it \MH/ Tutorial\/}\cite{MRose84b},
or the {\it \MH/ User's Manual\/}\cite{MRose85a}.

\item{$\bullet$}
Using the \pgm{msh} (``\MH/ shell'') program as a training shell to read
bulletin boards.
The \pgm{msh} command is an interactive program that provides some help
messages and can list available \MH/ commands.
\par}
\medskip

\noindent
No on-line tutorial materials are presently distributed with the \mh5
system, although there are some plans in the works to provide a program
to help with setting up the user profile that would also provide
operational tips for \MH/ and \unix/. 

It should be noted that these perceived defects of \MH/ do not affect its
utility any more than analogous problems with any operating system
will diminish its actual capabilities.
Users may quarrel with the means chosen for orchestrating \MH/,
but the fact remains that \MH/ is a very
useful set of mail handling tools that is flexible,
infinitely interoperable with other \unix/ text handling tools,
and yet simple enough for new users to grasp once they are given the 
proper start.
The fact that better tutorial materials and training do not exist only means
that some further work needs to be done in the area of user-education.

\section{A Few Advanced Features}		% mtr
We now consider certain advanced features in \MH/.
These features have been chosen to demonstrate some useful capabilities
available to the \MH/ user.
It should be noted that many capabilities of \MH/,
such as shell scripts for extensibility,
mail delivery hooks,
the personal aliasing facility,
and so forth,
are not described here for lack of space.

\subsection{Draft Folders}			% jns
The {\it draft folder} facility provides a method by which several
message drafts can be simultaneously composed and maintained until
sent.
The rationale for this is that partially composed message drafts,
perhaps elaborate sets of separate messages,
can be incrementally completed,
while a folder provides a consistent organization for drafts in progress.
This is comparable to similar situations in the ``paper world'' where
contracts, business correspondence, and other communications,
rather than being created serially with each posted in turn before composing
the next,
are usually left in various stages of
completion before they are eventually mailed.

The \eg{Draft-Folder:} parameter value in the \MH/ profile is used to
specify a default draft folder,
where each draft is given a number and an ``artificial'' date stamp.
Provided that the proper header fields have been completed,
a \pgm{scan} listing of the draft folder provides a summary of
each draft in progress:
to whom the message is to be sent,
the subject,
the date of the draft's initial creation and optionally,
the current size of the draft in terms of characters.
Experienced users of \MH/ may often keep as many as five to ten unfinished
drafts in their draft folder.
``Draft clutter'' can be remedied easily with the \pgm{rmm} command.

\subsection{Message Selection}			% stef
\MH/ commands accept {\it message sequence} specifications to specify which
\arg{msg} or \arg{msgs} are to be operated upon.
Here are some examples:
\example scan\ 1\ 3\ 5\ 19\ 185\endexample
to get a scan listing of messages 1, 3, 5, 19 and 185.
\example scan\ pseq\endexample
to get a scan listing of whatever message sequence was given to the previous
MH command (in this case 1, 3, 5, 19, and 185).
\example show\ first\ last\endexample
to get a display of the first and last messages in the folder.
The \MH/ sequences named \eg{first} and \eg{last} are system defined pseudo
sequences which act like explicit sequences when given to MH commands.
Others are \eg{cur}, \eg{next}, \eg{prev},
and \eg{all} which respectively specify the ``current'' message,
the ``next'' after cur,
the ``previous'' message before cur,
or ``all'' messages in the current-folder.
The \pgm{scan} assumes \eg{all} while show assumes \eg{cur},
unless overridden on the command line.
Over-ride precedence is: command-line first,
\profile/ second,
and compiled-in default last.

Users can define additional sequences for similar use,
but must avoid using reserved names.
A few optional sequence names have been preempted by \MH/,
such as \eg{pseq} to mean the
``sequence used by the previous MH command,''
and \eg{unseen} to mean the ``messages not yet seen by the user.''
Sometimes these preempted names can be changed by resetting them in the
user's \MH/ profile,
but these facilities are beyond the scope of this discussion.

The mark command can be used to set the values for user-defined sequences:
\example mark\ 1\ 3\ 5\ -seq\ zzz\\
	 mark\ 4\ 5\ 9\ -seq\ zzz\ -nozero\endexample
will create a user-sequence named \eg{zzz} and put the sequence \eg{1 3 5}
in it.
The \pgm{mark} command assumes that any prior content in an
existing user-sequence should be ``zeroed'' before the new sequence value is
recorded.
This can be prevented with a \switch{nozero} switch on the command line,
to add \eg{4 5 9} to the original \eg{1 3 5} to yield \eg{1 3 4 5 9}.
\example mark\ pseq\ zzz\ -seq\ zzznew\endexample
will create a new sequence named \eg{zzznew} and set its value to the combined
(inclusive or) of the existing user-sequences in \eg{pseq} and \eg{zzz} for
its value.

Another more powerful way to set the values of a user-sequence is with
the pick command, which provides full string search capabilities:
\example pick\ -from\ mrose\ -seq\ yyy\\
	 pick\ -from\ mrose\ -seq\ yyy\ -list\endexample
will search though all the \eg{From:} fields in the current folder for the
string \eg{mrose} and place the list of ``hits''
in the sequence named \eg{yyy}.
The \switch{list} switch will cause the resulting list to also be displayed on
the user's terminal.
If no \switch{seq\ name} switch is given,
pick will assume \switch{list}
and will simply display the resulting list of hits on the user's terminal.

This \switch{list} behavior of pick allows users to take advantage of the
\unix/ backquoting facility to embed searches in other \MH/ commands.
\example scan\ \bq{pick\ -from\ mrose}\endexample
will produce a scan listing of \switch{from\ mrose} hits because the
\unix/ shell will spawn a process to execute the
\eg{pick\ -from\ mrose} segment and return the \switch{list}
results as the message sequence to be scanned.
\example mark\ pseq\ -seq\ zzz\endexample
could then be used to capture the ``previous sequence'' in zzz for later use.

One last facility should be mentioned here.
It is also possible to negate a sequence to specify a new sequence.
The default negation string is \eg{not}.
\example scan\ notzzz\\
	 mark\ notzzz\ -seq\ zzznot\endexample
will give the user a scan listing of all the messages in the current folder
that are not included in the sequence \eg{zzz}.
The mark example will of course record the negation of zzz in zzznot.
It is a bad idea to use the string \eg{not} as the beginning of any
user-sequence name,
if \eg{not} is defined as the negation string.
(Users can choose a different negation string.)

From this discussion,
it should be clear that \MH/ provides a uniform set of ways to capture
and use sequences to augment the user's short- and long-term
memory and to manipulate lists of interesting messages.
User-sequences are normally stored as RFC822 labeled text lines in a file
(e.g., \sequences/)
in the folder with the messages referred to in the sequence.
If a user does not have write access to a folder,
then the \MH/ \pgm{mark} and \pgm{pick} commands will
create a ``private'' sequence in the user's \context/ file.
Switches are available to give the user control over
the choice of \switch{private} or \switch{public} sequence options.

Since user-sequences are stored as ordinary text lines in RFC822 labeled
fields,
there is no prohibition against someone writing programs to perform
any kind of useful manipulation on \MH/ sequences.
Boolean operators can be implemented,
or complex indexing structures could be developed to serve special purposes.
If a DBMS can utilize \unix/ pathnames or \MH/ \arg{+folder} and
message names,
then the full power of the DBMS might be applied.
The intention of \MH/ development teams has always been to leave open the
widest possible array of options for later extension.
The only restrictions should be the user's ingenuity,
programming prowess, and the available machine resources.
Unfortunately these resources always seem to be available in
limited quantities.