Install nmh with Homebrew, apk, apt, dnf, Nix, zypper

Project links

• Homepage
• Repository
• Upstream docs
• Package manager page

Commands and aliases

• anno
• burst
• comp
• flist
• flists
• fmttest
• fnext
• folder
• folders
• forw
• fprev
• inc
• install-mh
• mhbuild
• mhfixmsg
• mhical
• mhlist
• mhlogin
• mhmail
• mhn
• mhparam
• mhpath
• mhshow
• mhstore
• msgchk
• new
• next
• packf
• prev
• prompter
• refile
• repl

Project history

MH predates nmh by decades. RAND's 1979 user's manual describes MH as a UNIX shell-driven mail system where each mail activity is a separate command and each message is stored as a separate file in a folder directory. nmh continued that model as a mostly compatible replacement for MH, based on MH 6.8.3 from RAND and the University of California.

The nmh FAQ describes the fork as a response to the languishing state of MH: Richard Coleman created nmh from MH 6.8.3, added GNU autoconf, and fixed bugs and inconsistencies. Later maintainers moved the project infrastructure to Savannah, which remains the official source location.

Adoption history

nmh is niche by modern mail-client standards but important to Unix mail traditionalists because it preserves the MH composition model: commands such as inc, scan, show, repl, forw, refile, pick, sortm, and rmm compose naturally with shell scripts. The project page also points to front ends such as exmh and mh-e, showing that nmh is both an end-user toolkit and a substrate for other mail interfaces.

Package-manager coverage across Homebrew, Debian/Ubuntu, Fedora, Alpine, Nix, and openSUSE reflects long-tail adoption rather than hype adoption. Its value is continuity: scripts, habits, and mail stores built around MH semantics can keep working on contemporary Unix-like systems.

How it is used

Package nerds use nmh when they want mail to be shell-native. Typical workflows initialize a profile, incorporate messages into MH folders, scan folders, show or reply to individual messages, refile mail by shell command, and use pick/sortm/mhpath/mhparam in scripts. The practical appeal is that the mailbox is regular files plus small commands, so grep, find, cron, editors, and shell aliases remain first-class tools.

The tradeoff is intentional: nmh is not a turnkey GUI mail app. It rewards users who want explicit control over message storage, composition drafts, aliases, profile settings, and MIME handling.

Why package nerds care

nmh matters because it is a living bridge from early Unix mail design to present package ecosystems. It is a good example of a package whose significance is architectural and historical rather than measured by broad consumer adoption.

Timeline

• {'event': "RAND published The MH Message Handling System: User's Manual, documenting the shell-command and per-message-file model that nmh inherits.", 'year': '1979'}
• {'event': 'Richard Coleman created nmh from MH 6.8.3 after MH development slowed, adding GNU autoconf and cleanup work according to the MH/nmh FAQ.', 'year': '1990s'}
• {'event': 'nmh development infrastructure moved to Savannah and continued through the nmh-workers community.', 'year': '2000s'}

Related projects

• RAND MH
• exmh
• mh-e
• mmh

Sources

• https://raw.githubusercontent.com/mcr/nmh/master/docs/FAQ
• https://www.mankier.com/package/nmh
• https://www.nongnu.org/nmh/
• https://www.nongnu.org/nmh/old.html
• https://www.rand.org/pubs/reports/R2367.html