MH is an iceberg
From a comment on here:
MH of course is the example in the KornShell command and programming book as something that can be re-written as a series of shell scripts.
My immediate reaction is 'only as a very unsatisfying, slow, and incomplete version'. The Korn shell people shouldn't feel bad, though; lots of people have looked at MH and had that reaction, and some of them have even given it a try. Unfortunately it's much harder than it looks.
For all that I harsh on MH, one of the things that it does really well is hide a great deal of complexity behind a simple, easy to use exterior. It often manages to do this so seamlessly that you aren't even aware that what you're doing involves complexity. The end result is that what MH does feels simple and trivial when it's anything but.
For example, let's take the issue of what message or messages an MH command should operate on. One of the MH features is something called 'sequences'; a sequence is a possibly disjoint set of messages in a folder. Sequences are named, and you can tell a MH command to operate on a sequence by giving it the name of the sequence. A number of things in MH are implemented as sequences; for example, 'cur' (the current message) and 'unseen' (the unread messages in this folder) are both sequences.
You can support sequences in shell scripts, if you want to; I can think
of at least one plausible brute force representation. But it's not going
to be trivial or really fast because shell scripts simply don't have any
natural support for ordered sets, especially large ones. Or you could
skip supporting sequences and implement things like 'cur' and 'unseen'
with purpose-specific techniques, although this makes your system less
powerful and less like real MH. Since either way this is a significant
chunk of code, you're going to want to put it in some form of a shell
script library (either as a separate command that MH commands run to
find what to operate on, or as code that is directly pulled into scripts
.'); neither option is svelte and fast.
(In short, suddenly '
show' has stopped being a little shell script
that wraps 'less <filename>' with some handwaving to find out the
filename. Finding that filename, or filenames, is not so simple.)
This is just one example. Things like this are all over MH, as invisible support for common operations that people who use MH don't even think about. As a result, any shell script reimplementation of MH would be incomplete, hugely complex, and terribly slow (with the complexity and the slowness proportional to how incomplete; the more incomplete, the simpler and faster). The only way to get a simple shell script version of MH is to throw out almost all of what makes MH decent to use in the first place.
The same more or less holds true of reimplementations of MH in serious
languages. Any reasonably full featured MH clone is going to have much
of the same work happening behind the scenes, which makes it nowhere
near simple to write. You need quite a lot of code to get to the point
scan unseen' or '
repl 10' or '
refile +pending' just work
right (and that's ignoring the people who've customized their behavior).
The end result is that there are a lot of partially started incomplete reimplementations of MH, some basic reimplementations of parts of MH that make their author happy but probably not anyone else, and no general simpler reimplementation of MH that I know of.
Sidebar: the other problem with MH reimplementations
MH has a lot of baroque functionality. Everyone who uses MH (and knows about this functionality) agrees that most of it can be dropped as stupid and unnecessary. Unfortunately, everyone who uses MH has a somewhat different idea of which specific bits are absolutely useful and important and have to be kept, and which bits are stupid and unnecessary and should be left out of any reimplementation. Name your favorite obscure MH feature and there are people who are very attached to it and other people who never touch it.
I am not an exception in this. I have my own set of crazy MH bits that I use, and I would be pretty much completely uninterested in an MH reimplementation that left them out entirely and simply hard-coded a single 'common' behavior.