On Jun 23, 2018, at 5:18 PM, Grant Taylor via TUHS <tuhs(a)minnie.tuhs.org> wrote:
I actually have no idea of nmh, but i for one
think the sentence of the old BSD Mail manual stating it is an "intelligent mail
processing system, which has a command syntax reminiscent of ed(1) with lines replaced by
messages" has always been a bit excessive. And the fork i maintain additionally said
it "is also usable as a mail batch language, both for sending and receiving
mail", adding onto that.
What little I know about the MH type mail stores and associated utilities are indeed
quite powerful. I think they operate under the premise that each message is it's own
file and that you work in something akin to a shell if not your actual OS shell. I think
the MH commands are quite literally unix command that can be called from the unix shell.
I think this is in the spirit of simply enhancing the shell to seem as if it has email
abilities via the MH commands. Use any traditional unix text processing utilities you
want to manipulate email.
MH has always been attractive to me, but I've never used it myself.
One of the reasons I continue using MH (now nmh) as my primary
email system is because it works so well with Unixy tools. I
can e.g. do
pick +TUHS -after '31 Dec 2017' -and -from bakul | xargs scan
To see summary lines of messages I posted to this group this
year. Using MH tools with non-MH tools is a bit clunky though
useful; I just have to cd to the right Mail directory first.
A mail message is really a structured object and if we
represent it as a directory, all the standard unix tools can
be used. This is what Presotto's upasfs on plan9 does. With it
you can do things like
cd /mail/fs/mbox
grep -l foo */from | sed 's/from/to/' | xargs grep -l bar
But you soon realize standard unix tools are quite a bit
clunky in dealing with structured objects - often you want to
deal with a set of sub components simultaneously (e.g. the
pick command above). This problem is actually pretty common in
the unix world and you have to have context/target specific
tools. At the same time a unix sensibility can guide the
architecture / design. Something like MH toolset would be
easier to implement if you assume an underlying mbox
filesystem. Conversely, the same sort of tools can perhaps be
useful elsewhere.
\vague-idea{
Seems to me that we have taken the unix (& plan9) model for
granted and not really explored it at this level much. That
is, can we map structured objects into trees/graphs in an
efficient way such that standard tools can be used on them?
Can we extend standard tools to explore substructures in a
more generic way?
}