[TUHS] mail (Re: off-topic list

[Bakul Shah]

On Jun 23, 2018, at 5:18 PM, Grant Taylor via TUHS <tuhs at 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?
}