[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: norm
Subject: Re: [Nmh-workers] What are and what should be the qualifications for a current nmh user
Date: Sat, 08 Nov 2014 14:34:32 -0800

Ken Hornstein <address@hidden> 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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]