text.tex

早期freebsd实现

programs to accomplish complicated or specialized tasks.

\tagdiagram{7}{The \pgm{mpick} Script}{mpick}
For example,
in the \MH/ distribution there is a shell script
called \pgm{mpick} (shown in Figure~\mpick)
which tries to locate all the messages which pertain to a given discussion,
by looking at the \eg{Message-ID:} and \eg{In-reply-to:} headers,
to find matching message-ids.%
\nfootnote{Note that the shell scripts included in the \MH/ distribution
are written for the {\it Bourne} shell,
and have a `:' as the first character of the first line,
so they will be portable to all versions of \unix/,
not just those which support the
Berkeley `\#!' enhancement.}

\tagdiagram{8}{The \pgm{append} Editor}{appended}
Unfortunately, some parts of \MH/ are somewhat monolithic.
An example of this is the \whatnow/ prompt.
There are only a few options at this prompt,
and one cannot give a normal shell command.
Some \MH/ users seem to feel that more options should be added to
the \whatnow/ prompt, such as an \pgm{insert-file} option.
It was argued that just about any editor would allow you to 
insert a file, and another \whatnow/ option was not needed.
These users persisted, however, so the
problem was solved, by writing a trivial shell
script ``editor'' (see Figure~\appended)
which could be invoked by the \pgm{edit} option:
\example What now?\ edit\ append\ filename\endexample

A better interface at this point is really needed, however.
One possibility is to simply pass any unrecognized commands on
to a shell for interpretation, supplying the path name of the draft file
as an argument.
A solution which shows more promise is to give you a sub-shell
{\it instead} of the \whatnow/ prompt,
and setup certain envariables so that
the \MH/ commands would act upon the \file{draft} by default.
For example, \pgm{show} with no \arg{msgs} arguments
would show the draft instead of the current message.
This alternative has recently been implemented and is under testing.

\section{The \MH/ Distribution}			% mtr
The \mh5 distribution is now briefly described,
both in terms of static configuration methods
and dynamic tailoring.
Appendix~B describes the mechanics of receiving an \mh5 distribution.

\subsection{Configurable \MH/}			% jlr
The \MH/ distribution currently runs on a large number of different \unix/
versions,
ranging from MicroSoft XENIX to Berkeley 4.2\bsd/.
All the code which is specific to a particular target environment is
enabled via the C-preprocessor \eg{\#ifdef} mechanism,
so compilation under different versions of \unix/ is trivial.
There are,
however,
a large number of compile-time options which may vary from site to site,
so an automated configuration method was needed.

\tagdiagram{9}{Sample \MH/ Configuration File}{mhconfig}
The \MH/-installer must create a configuration file,
which contains a list of the compile-time options
and the values which are desired for them.
Compile-time options include the installation location for \MH/,
what kind of message transport system is to be used,
and the default editor for the installation.
An example of such a configuration file is shown in Figure~\mhconfig.

After creating this file (several examples are included in the distribution),
the installer runs the \pgm{mhconfig} program,
which customizes the \file{Makefile\/}s and some of the programs,
for that site's particular installation.
No hand-editing of any source code should be necessary,
under normal circumstances.

\subsection{Interface to the Message Transport System}	% jlr & mtr
\MH/ will run with a number of message transport systems,
including \SendMail/, \MMDFII/, and a small stand-alone system.
One flexible method of posting mail is through an SMTP connection.
There are a couple of major wins in using this configuration: 
First,
none of the \MH/ programs need to know where the interface programs to
the message transport system are located,
which makes them easier to move between systems.
Second,
mail can be posted on relay hosts,
and the local host of an \MH/ user may not need a message transport system at
all (as alluded to in the preceeding discussion on the POP).

\tagdiagram{10}{Sample MTS Tailor File}{mtstailor}
Those parts of \MH/ which interact with the local message transport agent
read additional tailoring information when they start.%
\nfootnote{This simple facility is based on a more extensive
tailoring capability found in \MMDFII/.}
This information includes
the location of standard and alternate maildrops,
maildrop delimiter strings,
the locking directory and locking style,
and other tailoring information specific for the particular
message transport system in use
(e.g., the default server search-list when mail is posted with the SMTP).
In most cases,
by using a tailor file,
each site running a similar \MH/ configuration is able to simply transfer
\MH/ binaries between hosts.
An example of such a tailor file is shown in Figure~\mtstailor.

A continuing question which is often raised is how intelligent should user
agents (like \MH/ and UCB \pgm{Mail}\/) be with respect to the environment in
which they operate.
At present, \MH/ likes to determine 
the official hostnames for addresses when posting mail.
Many argue that this is improper or unnecessary behavior for a user agent,
and that the local message transport agent should handle these functions.
Unfortunately,
this implies that the message transport agent should munge headers when mail
is posted to remove local host aliases and only permit address fields with
fully-qualified addresses.
Sadly, neither \SendMail/ nor \MMDFII/ really gets this right
(flames to \file{/dev/null} please).
The current \MH/ maintainers believe that the resolution of host aliases to
official names should be a well-supported interface with the local message
transport agent.
However, to provide equal time to those who hold opposite views,
\MH/ supports a configuration option called \eg{DUMB} which disables \MH/'s
attempts to resolve addresses into fully-qualified strings.

\section{Concluding Remarks}			% jlr and mtr
While \MH/ has undergone significant development since
the original
Rand release, the authors have
tried to keep the fundamental concepts of
\MH/ unchanged.
						% specific vs. general
The authors have continually had to battle against
well-meaning \MH/ users who wanted to make \MH/
more like other (less powerful) user agents.
More and more ``features'' were often suggested for \MH/,
usually at the expense of making \MH/ less general, and more specific.
In nearly all cases, the ``features'' which these users wanted
were already present in \MH/ in a slightly different form,
or could be realized by simply writing a short shell script.
A classic example is the repeated requests by one user to have \pgm{dist}
take a list of messages rather than a single message and distribute each one
of them in turn.
A simple shell script which called \pgm{dist} repeatedly,
perhaps with ``canned'' arguments so the user typed in addressing information
only once, would easily meet this request.

						% generality
A number of \MH/ comands have a large number of options.
When adding options, the authors have tried to make the options
general, while still accomodating the requests of specific users.
An example of a specific request which was implemented as a
general feature is the \eg{Previous-Sequence} profile entry
(mentioned above).
If you use this profile entry, every \MH/ command is forced to write
out \context/ changes, making every command somewhat slower.
Since only a few users wanted this capability, it was implemented
in such a way that users who didn't want it, didn't have to pay
the cost of slowing down every \MH/ command.

						% naive user :: MH
\MH/ has a powerful tailoring capability provided by the \profile/.
Using profile entries, users may
customize their own environment without affecting others.
Novice users often take advantage of the \MH/-tailoring
capabilities to try to make \MH/ work similarly to
other user agents they've used.
This has the advantage of allowing them to quickly begin
using \MH/ to handle their mail.
However, since these novice users don't take advantange of all the
capabilities of \MH/,
they frequently will complain about things they think can't
be done with \MH/, or could be done ``better'' some other way.
Fortunately,
as these users become more experienced with both \MH/ and \unix/,
they can modify their environment to take better advantage of
all of \MH/'s capabilities.
Novice \MH/ users who see features lacking
are encouraged to take a better look at what \MH/ {\it can} do,
instead of trying to make \MH/ into something it isn't.
This may sound rather inflammatory,
but it would really be a much nicer world for us all if users of software
systems would read the manual prior to asking questions.

						% speed consideration
For a moment, let's consider the evolution of one \MH/ feature which has
proved itself to be very useful.
As users began employing \MH/ to handle their mail,
the number of messages that could be processed
in a given amount of time increased greatly.
As the volume of messages increased however,
it became clear that some \MH/ operations were too slow,
in particular the interaction with the (slow) message transport system.
To overcome this problem, the \pgm{push} option
was added at the \whatnow/ prompt.
Originally, this option was hidden from novice users
and did little more than send the message in the background:
any output generated by
the background \pgm{send} process would be printed
asyncronously on the terminal.
If a message failed posting with the message transport system,
it would simply be left in the \file{draft} file.

Gradually, other features were added to \pgm{push}.
Since users wanted to be able to send more than one draft
at a time, \pgm{push} was changed to optionally
rename the draft file before posting it.
(This is what the hidden \switch{unique} option does.)
Having message transport system diagnostics
written asyncronously on the user's terminal was annoying,
so \pgm{push} was made to intercept these diagnostics,
and mail the user a report containing them.
Although the diagnostic report mailed back by \pgm{push} contains
the name of the draft which failed,
a useful added feature was the ability to have \pgm{push}
include the failed draft as well.
Eventually, the draft-folder mechanism was implemented to make
handling multiple message drafts much easier.


\subsection{TODO}				% mtr
There are, no doubt, a number of improvements which could be made to \MH/.
At the present time,
what further development should \MH/ suffer?
Although not by any means inclusive,
here's a list:
\smallskip
{\advance\leftskip by\parindent
\item{1.} Performance Enhancements\hbreak
Hardware gets faster all the time, but people always complain that software
is too slow.
Owing to its user interface style,
\MH/ is somewhat slower than monolithic programs like UCB \pgm{Mail}.
It would be nice if \MH/ could be tuned or accelerated somehow.

\item{2.} Port to System~5\hbreak
\MH/ runs on 4.2\bsd/~\unix/ and Version~7 variants.
It should not be difficult to port \MH/ to a SYS5 environment.
This should significantly increase the number of hosts
on which \MH/ can run.
The authors,
lacking a SYS5 machine (and experience with SYS5) to perform the port,
are actively seeking a System~5 guru to attempt this feat.

\item{3.} Interface to the Network News\hbreak
Not all sites that run \MH/ are in the ARPA Internet,
and as such the UCI BBoards facility may not be of much use to them.
A good \MH/ interface to the network news would allow users on hosts with a
news feed to employ the same interface for reading and sending both mail and
news.

\item{4.} Programmed Instruction for Beginners\hbreak
The complexity of \MH/ is often intimidating to new users.
It would be nice to develop a set of \pgm{learn} lessons for those users who
don't like \pgm{man} pages and non-interactive tutorials.

\item{5.} Message List Expansion\hbreak
At present, when a list of messages is given to an \MH/ command,
it expands the list and processes each message in numerical order
rather than the order in which the messages were given
(e.g., \eg{show\ 2\ 1} \pgm{show\/}s message~1
and then message~2).
It would be nice if \MH/ processed messages in the order
they were given.

\item{6.} Context Changes\hbreak
In nearly all cases,
an \MH/ command does not write out context changes until it is about to exit
successfully.
There is some controversy as to whether this is the correct behavior
in all cases.
Some argue that once an \MH/ command has fully parsed its argument list,
the context should be updated.
\par}