The tragedy of MH
August 14, 2011
At its fundamental core, MH is one of the most Unix-y mail programs going, because its two core ideas are that you should put each message in a separate file and that each mail command should be a separate Unix command. Ignoring practical considerations for a moment, these ideas are utterly the right way to do a mailer on Unix because both of them let you leverage other Unix tools and shell scripting. Also, since MH simply uses Unix directories to represent mail folders it has a natural way of allowing and representing nested folders.
Unfortunately, the actual implementation of these ideas is rather terribly non-Unixy. Some of this is (or was) forced by implementation issues, but much of it is by choice. For example, MH implements a completely baroque string processing language that's used to format information from messages in various situations (for example, scanning a mail folder or replying to a message). The net effect is that actually using MH commands does not feel very Unix-y, apart from the fact that you're doing so in your shell; the arguments are odd, the configuration process is odd, and so on.
(The source code is also rather non-Unixy, including things like its own weird config and build system.)
The net result feels like its creators had a couple of brilliant moments of Unix insight and then promptly forgot it all in favour of a typical plodding big complex system implementation, complete with the kitchen sink. And I've always thought that that is the tragedy of MH; that such a Unix-y core idea has wound up wrapped in a very non-Unixy everything else.
(A disclaimer: I like MH and have for a long time; it's one of those rare Unix programs where I had a visceral 'this is the right answer' reaction from the moment that I first saw it. I've been using MH for more than 20 years now. But I am not blind to its flaws.)
* * *
Atom feeds are available; see the bottom of most pages.