In general, each UNIX computer has two kinds of programs that handle mail:
Figure: How a mail message gets from A to B
But when you start to do more with email, you'll want a user agent that saves you time, lets you organize messages the way you want to, and helps you find messages you've stored. You'll probably want to automate routine work. You might even customize your email setup so it works exactly the way you'd like it to. This is where advanced, flexible systems like MH stand out.
Here's a quick comparison of user agents.
Most user mail agents are monolithic: you're in the mail program until you quit out of it. To start the program, you type its name, like mail, at a shell prompt. (The shell prompt is shown as a percent sign (%) here; your prompt may be a dollar sign ($) or something else.) Then that program takes over -- it reads and executes all the commands you type until you use its quit command.
For example, here's how you would read, print, and delete two mail messages with the standard UNIX program named mail:
% mail
Date: Mon, 09 Jan 1995 07:53:55 EST
From: nancyo (Nancy O'Leary)
To: jdpeek
Subject: meeting
I'm free at 3 today. Is that okay?
? s toprint
Date: Mon, 09 Jan 1995 08:54:22 EST
From: biffj (Biff Jameson)
To: jdpeek
Subject: the meeting
I can be there at 11 or 3 today.
? s toprint
% lpr toprint
% rm toprint
You show the first message on the screen. At the first prompt
(which is a question mark (?) in this program), you give
the command to save the message in a file named
toprint, which also automatically deletes the message.
(You're saving to a file because you can't print directly from
this particular mail program.) You read and save the next
message in the same file toprint. The mail agent
automatically quits because it's given you all the messages. Then
you print the messages you saved and delete the toprint
file.
Most mail agents have more commands built in. For instance, many have a command for printing a message directly. A lot can send a reply to or a copy of a message. Some let you organize messages into groups. Most also let you type a single UNIX command without leaving the mail agent: that's called a shell escape.
Monolithic mail agents keep all of the messages in your system mailbox or a file in your account named something like mbox. These are single files which hold all mail messages together. The messages are separated in one of several ways. The mail agent knows how to parse (split) them into separate messages, but this format makes it harder to do complex things like rearranging the order of the messages.
Here's the same example using MH. (nmh, the new MH, works the same way.) Because MH commands aren't part of a monolithic mail agent, you type all the commands at the shell prompt:
% inc
Incorporating new mail into inbox...
1+ 01/09 Nancy O'Leary Meeting<<I'm free at 3 today. Is that
2 01/09 Biff Jameson the meeting<<I can be there at 11 or 3
% show
(Message inbox:1)
Date: Mon, 09 Jan 1995 07:53:55 EST
From: nancyo (Nancy O'Leary)
To: jdpeek
Subject: meeting
I'm free at 3 today. Is that okay?
% next
(Message inbox:2)
Date: Mon, 09 Jan 1995 08:54:22 EST
From: biffj (Biff Jameson)
To: jdpeek
Subject: the meeting
I can be there at 11 or 3 today.
% show 1 2 | lpr
% rmm 1 2
Because MH commands aren't part of a
monolithic mail system, you can use them at any time; you don't
have to start or quit the mail agent. It's fine to mix other UNIX
commands between your MH commands, to leave your mail for a while
and do something else, and to work at several terminals at the
same time. Because you use MH commands from a shell prompt, you
can use all the power of the shell. For instance, I used a pipe to
send the output of the show command to the printer
directly. I removed the two messages after sending them to the
printer.
If your shell has time-saving aliases or functions (and most do), you'll be able to use them with MH. And because MH isn't a monolithic mail agent, you can use MH commands in UNIX shell scripts or call them from programs in languages like C or perl.
Unlike most mail agents, MH keeps each message in a separate file. The filename is the message number. To rearrange the messages, MH just changes the filenames. MH can use standard UNIX filesystem operations such as removing, copying, and linking on its messages. The message files are grouped into one or more folders, which are actually UNIX directories.
The MH setup has a lot of advantages. A significant disadvantage is that it takes more filesystem space to store the messages. See the Chapter Key Parts of the UNIX Filesystem for an overview.
After almost twenty years, development of MH seems to have stopped. Most activity is with nmh, the "new MH". Although nmh is mostly backward-compatible with MH, its user interface is evolving. And the nmh internals are becoming a lot different than MH: old limitations are being removed, security is improved, and installation is much easier.
This book explains differences between MH and nmh at the place that seems the most logical to me--usually in the general introduction to a command or feature. For a concise list of user interface changes, read the file DIFFERENCES in the top-level directory of the nmh source tree. (You can also compare the MH and nmh manual pages for a particular command. But the nmh manpages tend to be more complete--and to document MH features that weren't well-documented before.) The ChangeLog file in the top-level directory of the nmh source tree has a fairly detailed list of changes, version by version, as nmh evolved.
The xmh, MH-E and exmh programs are something like a monolithic mail agent; they each have an interface with a limited set of commands. But they actually run MH commands for you; if you need to do something that you can't do with the interface, you can always use the MH command instead. MH-E, exmh, and xmh are examples of what I call a front end. A front end is a program or set of programs that is an interface to MH commands. They let you do some of the most common things you need from MH, usually by pressing a single key, clicking a button, or using a menu. In fact, if you know how to write a program in some UNIX programming language -- such as the Bourne shell, Perl, or Tcl -- you can write a front end to MH. One Chapter of this book has tips for programming with MH.
The Figure below shows typical sessions with MH, xmh, MH-E, and exmh. If you decide that a front end to MH (like xmh) is right for you, it's still a good idea to get familiar with the rest of the MH commands and features. That's because there's a lot in MH that you might need -- to make your email use easier or more efficient -- that your front end may not let you do easily, if at all.
[Here is a more-detailed (higher resolution) version of the figure above.]
xmh comes with the X Window System from the X Consortium. It's built with standard parts of X. If you're familiar with X and know how to customize the X Toolkit, you'll feel right at home with xmh. Even if you don't want to customize xmh, the "out of the box" design makes it easy to use MH commands without using the UNIX command line.
If you use the GNU Emacs editor, or you use a terminal that doesn't "do windows," MH-E can be a great choice for an MH front end. It gives you all the power of GNU Emacs -- including the ability to divide a standard non-windowing terminal into multiple windows. Many of the commands take only a single character.
The exmh interface looks something like xmh. It also runs under the X Window System. But instead of the X Toolkit, exmh is built with Tcl/Tk. By default, exmh is far more powerful than xmh. One major difference is that exmh can read and send MIME multimedia mail. But, while xmh is stable and hasn't changed much in the last two major releases of X, exmh is evolving quickly. If you aren't interested in being on the "bleeding edge" of email technology and updating your software fairly often (as bug fixes and new versions are announced), exmh may be worth watching from a short distance away.
There are many other interfaces to MH as well -- too many to mention here. You can read brief summaries about them in the FAQ, the Frequently Asked Questions document that is posted regularly to the Usenet newsgroup comp.mail.mh. In fact, the FAQ contains so much good information that it could be a part of this book. But, because the FAQ changes so often, we thought it would be better just to tell you how to get it.
