nmh-workers
[Top] [All Lists]

Re: [Nmh-workers] What are and what should be the qualifications for a current nmh user

2014-11-08 16:35:00
Ken Hornstein <kenh(_at_)pobox(_dot_)com> writes:
Yes, many commands, such as ls, mv, rm, amd chmod will still work, BUT many,
such as grep, sed and awk will not work. At least not until you supply some
additional commands. You ask, 'what are those commands?'. I don't know; I
don't know MIME well enough to answer that question. But, maybe, your Email,
'vague, undefined thoughts on nmh MIME processing", of 'Wed, 16 Jul 2014
00:30:13 -0400', has the clues.

When I was talking about "commands", I meant "MH/nmh commands", not generic
shell commands. But here's another meta-question for you: what's the real
innovation of MH?

If the answer is, "Individual shell commands to operate on messages versus a
monolithic MUA", or even, "Users can create and edit message headers directly
for the utilities to operate on", then you don't really care if Unix
utilities don't work directly on the messages.

If you think the MH innovation is the message store, then you do care that
Unix utilities not working on the raw messages.

I went back to the original Rand Note, "The Design of the MH Mail System",
which Norm is listed as a co-author on. The two main design decisions
enumerated are:

- MH commands -- the primitive operations on a message -- are UNIX shell
commands; and - Each MH message is a normal UNIX file.

Okay, that suggests all of those things are important. But if you read the
rest of the note, in terms of Unix utilities all that is really mentioned is
using your favorite text editor ("e" and Word Perfect are mentioned!) to
compose messages. Everywhere else the note talks about using MH utilities on
messages as opposed to generic UNIX text processing commands. Maybe this was
so obvious the note didn't think think to mention this; Norm, if you could
give us some idea what you guys were thinking, it might be helpful.

What we were thinking or wrote nearly four decades ago, should not have much
impact on your thinking today, or in any way bind you.

I don't remember, well, what Stock and I were thinking 37 years ago. But, to
put the memo in prospective, it was not so much a design document, but a
political document designed to convince Bob Anderson (then head of Rand's
Computer Science Department) and others that we should pursue, that
alternative as opposed to the monolithic approach, MS, that was then being
pursued. We failed. Bob decided to stay with MS. It was only months later,
when Bruce Borden, who had subsequently been hired to head the MS team, came
across the memo, that actual design discussions began.

FWIW, I always thought the real innovation was the shell command interface
and the user-editable headers; to me, the message store is really more of an
artifact of the implementation.

But the fact that messages are files is tightly wound with the use of the
shell as the interface to MH. To the best of my recollection, when I first
approached Stock with the idea, I discussed only that MH commands should be at
the shell level, and that messages should be files. The kind of details in the
memo, were just for persuasion and to put some meat on the issue.

I don't know to what extent, if any, I considered the the way messages would
be represented as files. I'm guessing that I considered the question obvious,
IF I considered it at all.

I do, very vaguely, remember some discussion about whether messages should be
directories, and the components of a message should be files, but that it was
dismissed as too radical and inefficient.

I do not remember when I startated reciitng the mantra, "All power to
the user". l do know that it is a play on "All power to the soviets",
politcal slogan from the period beteen tge two Russion revolutions,
about which I was reading in the mid 1970's.


But MIME has sort of changed the game; nowadays messages are a lot more
complicated than they were back then, so I'm unsure how to make traditional
UNIX text processing work in the general case. We provide programs already to
search messages (like 'pick'); it seems to me that the only logical direction
to go is make the nmh commands smarter about MIME.

I found that message quite exciting. I grant, that you were not thinking of
external commands, but I think, maybe it contains the germ of an answer to
the question.

Note that message was just talking about MH internals; the UI wouldn't really
change. Nor would the message store. So I'm not sure it would help the
external command case.




    Norman Shapiro

_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

<Prev in Thread] Current Thread [Next in Thread>