This page shows some random examples of using the MH electronic mail system.
Most examples aren't common day-to-day operations like sending and
reading mail; instead, they show things that make MH unique and special.
If you haven't used MH, and you haven't read the
MH history page yet, that page gives
some background to help you understand what's going on.
I'll show examples on the Unix command line.
If this isn't familiar to you, or if you'd rather use a graphical
(GUI) interface to your email, please keep in mind that there are
interfaces to MH -- like
that hide the command line from you.
Underneath, though, those interface programs are running commands much
like the ones I'll show here.
Reading Messages into Other Programs
Links: Putting One Message into Many Folders
Annotating and Editing Messages
When you start typical email programs, they give you some kind of
"default" view of your messages.
For instance, they might start by showing a list of all of your
mail folders or a view of the first message in your inbox.
MH is different.
It keeps context.
Among other things, it remembers your current folder and current message
in that folder.
It keeps that context until you do something to change it -- like
reading another message or looking into another folder.
This means, among other things:
You can go to lunch, go home for the night, shut down your
computer, or whatever.
When you come back, MH will remember where you were before.
For instance, if you type the show command, you'll see
the same message, in the same folder, that you were reading before.
You can have multiple MH commands running simultaneously.
For instance, in one window you could run show 23 to
show message number 23.
In another window you could run next to show the
following message, remove that message (by typing rmm),
then show the next message (run next again).
The first window will still be showing message 23.
MH also lets you override the context and/or have many contexts.
(Simply set, or un-set, the MHCONTEXT environment variable.)
For instance, if you want to read another message without
changing the current message number, you can use a simple program
(like my tcx) that runs an MH command with no context.
Or, if you want each of your terminal (shell) windows to be separate
from each other, simply give each window its own context.
Most email programs store email messages in a "folder" which is
actually a big file full of many messages.
MH is different: it keeps each message in a separate file named
1, 2, 3, and so on.
(The filename is the message number.)
The files are grouped into Unix directories; each directory
is a separate folder.
The mhpath command gives the absolute pathname (the
exact location in the filesystem) of a message or folder.
This makes it easy to grab an MH message from another (non-MH)
Because MH also keeps context, you don't
even need to know the current message or folder!
Here are some example MH commands, typed on a Unix command line:
...Message 23 from the inbox folder appears...
$ mhpath (shows pathname of the current folder)
$ mhpath cur (shows pathname of the current message)
$ mhpath last (shows pathname of the last message)
So, for instance, the vi text editor has a command
:r for reading in a file.
You could read the current MH message into vi by typing
(with Unix command substitution):
:r `mhpath cur`
(If the message is MIME-encoded, you may want to use the
mhstore command to decode it first.)
MH is almost infinitely customizable, so you can make it do a lot
of things that other email programs can't.
Here's some of why:
MH isn't one big email program.
It's a group of small programs -- each of which, in the Unix style,
does just one thing.
(For instance, the show program shows messages.
The comp program composes a new message.
The refile program moves a message to another folder.
And so on.)
If you're a programmer (in Perl, Java, C, the shell, or whatever),
you can also write your own MH program to do just what you want;
it can either call the basic MH programs (refile, for example)
or it can do something that no other MH program does.
Because the MH architecture is open and flexible (for instance,
each message is in a separate file),
your program can access messages directly without complicated
file-parsing and locking.
You can also develop programs that call these smaller programs.
For instance, if you want to make a graphical interface to MH,
you can do it. Simply clicking a "compose new message" button,
for instance, calls the MH comp command.
Your interface can run the MH scan command to get a
summary of the messages in a folder, then display that summary
in whatever format you want.
(Green message numbers? No problem.)
Two popular interfaces to MH are
The output of many MH commands is formattable.
For instance, if you don't like the way that scan lists
the contents of a folder, you can write a new format string or
format file that outputs message data in any order, any column
width, on multiple lines, with labels... and more.
If that's still not enough, then -- because scan is a well-behaved
Unix program that writes text to its standard output -- you can feed
the output of scan to other programs (such as the Unix
utilities sort and column) -- to get just what you
Each MH command has command-line options that let you control it.
For example, refile moves messages from the current
folder to another folder.
Adding the -src option lets you move messages from some
The repl command accepts a handy -query option that
asks you, one by one, whether you want to send your reply to each of
the addresses in a message.
There are many more examples.
Options that have a "yes/no" or "on/off" quality can be switched off.
For instance, if -query is the default, but you want your
reply to go to everyone without being asked, you can run repl
-noquery to override the default.
(Defaults are set in the MH profile. See below.)
If you always want to use a particular option with a particular
command, you can store that option in the MH profile.
For instance, the MH profile entry repl: -query
tells repl always to use its -query option.
You can override these defaults on the command line, as we explained
earlier about repl -noquery.
You can get more flexibility by defining multiple names for a single
command, and giving each name its own MH profile entry.
For instance, if you've set repl to use its -noquery
option by default, you could define a command named, say,
replq, which runs repl -query.
This is simple to do: make a symbolic link named replq
that points to the repl program, then make
an MH profile entry replq: -query.
As explained earlier, the default options for MH commands are set
in an MH profile file.
You can actually have multiple MH profiles.
One profile might be for interactive use, and another for when you
call MH programs from an automated cleanup script.
(Another of the many advantages of MH is that, because it's made of
many small programs, other programs can call MH programs to automate
tasks that other email programs might force you to do by hand.)
Or, you might want one profile for work on personal mail and
another for work on shared mail folders
(when you're working on a helpdesk, for example... MH is designed
so that multiple users can share the same mail folders!).
Most email systems make a mail "folder" by putting many email
messages into a single file.
If you have a lot of mail folders, it can be hard to remember
which mail folder has the message you want.
One answer is to put a copy of the message in any folder where
you might look for it.
But that has (at least) two problems: wasted disk space and making
all of those copies hard to find if you want to remove the message
from your folders.
Because MH keeps each message in a separate file,
it's much easier to keep a message in multiple folders.
The MH command refile -link "copies" a message into another
Even better, it doesn't actually copy the message; it makes a
hard link -- a feature of Unix filesystems that lets you
keep a file in multiple directories (multiple folders) without taking
any extra disk space!
If you ever want to delete those linked messages, cleanup is easy.
The Unix command find -inum finds hard links.
An email message has two parts: the header (with lines
like From: Joe Doakes <email@example.com>) and the
body (the text of the message).
Most email programs "protect" the header and body from you;
they'll only let you change them little, if at all.
MH -- like most Unix programs -- assumes that you know what you're
It doesn't put restrictions on you.
The messages are in files,
and you can edit the header or body any way you want to.
Here are some ideas:
You can add fields (lines) to the header with the MH anno command.
For instance, I've written a little program named
drmm that adds
a header field like X-remove-after: 23 Jul 2003.
Once a week, another program (run from my system's Unix cron
facility) looks through my MH folders and removes any messages
that are past their X-remove-after: date.
MH can also automatically annotate messages when you reply to them,
forward them, and more.
Look for the -anno option.
(The -inplace option makes sure that any links to a message
aren't broken -- so all "copies" of your message, in all folders,
will be annotated at once.)
The MH pick command finds messages based on what's in their
header and body.
For instance, the command pick -datefield X-remove-after -before
today finds messages that my drmm program annotated;
This is how my cron job finds my "outdated" messages
and removes them.
Do you get tired of people sending you huge email replies, with
tens or hundreds of quoted lines of previous messages, and all that's
really new is their one-line reply?
That wastes disk space; it also can mean that you need to search
through all of the quoted text, each time you re-read this message,
to see whether there's anything new in all that quoted junk.
MH lets you edit the message body.
So you can remove everything except the actual reply.
(You might want to add something like ...original message deleted by
If the message has the same text repeated, in both plain text and
HTML, you can also remove the entire HTML section (and the MIME
header fields that show it's a multipart/alternative message).
(Suggestions? Please click the link below to send me email.)
[Email tips page]
Last change: 4 July 2003
Contact Jerry Peek