🚀 go-pugleaf

From article <113567@sun.Eng.Sun.COM>, by argv%eureka@Sun.COM (Dan Heller):
> I don't want to discuss the entire feature list of Mush; the man page is
> 50 pages long.  But, Mush does provide similar features like "pick" and
> other functions that MH provides.  It does provide "piping" of commands,
> sorting of messages, etc..  The point is that these features can be provided
> regardless of the storage method of folders.  The fact that many of the
> features of MH happen to be replicated (there are some very good ones),
> is a side effect of good design.  However, MH has some poor design schemes
> that warrant the writing of a new MUA.  So, I'm not reinventing the wheel
> with writing Mush, but instead I hope to provide a "new and improved" model.

Several people make the statement that MH has some 'poor design schemes',
can you elaborate on those that you feel make it deficient? 

> There are many things wrong with MH in this respect.  Not only is it huge,
> but it *really is* hard to learn.  I remember when I first went to SRI, I
> was set up with MH by default.  I spent hours reading all sorts of doc
> and experimenting with commands and so on... I was really put off by the
> fact that all my mail was moved and split up.  I struggled with it for a
> while, but was further put off by the fact that it was so slow.

I still think that MH documentation is quite poor, so I have not problems
with people making these statements, most are real life accounts.  The
MH way of handling mail is different.  Let me fill in those who are reading
and don't know anything about MH.

MH uses a directory hierary for storage.  An MH folder is a directory.
Each message in that folder is a file in the associated directory.  A
single file called .mh_sequences contains the information about that
folders "sequences".  These are arbitrary names which a message can
be known as.  The line 'unread: 1-5' in the sequences file means that
messages 1 through 5 are in the unread sequence.  There is a tool called,
mark, which allows sequences to be created and manipulated.  Preallocated
sequences are 'cur', for the current message, and the 'Unseen-sequence'
which you can name yourself (some call it unseen, I use unread).  The
basic operation of MH involves getting your mail into a folder where
you can look at it (MH works with SENDMAIL, MMDF and standalone UUCP
as MTAs).

The MH command line syntax is as follows.  Options are specfied by a
'-' followed by 1 or more characters.  E.g. the command 'inc -help'
produces

syntax: inc [+folder] [switches]
  switches are:
-audit audit-file
-noaudit
-[no]changecur         
-file name
-form formatfile
-(forma)t string       
-[no]silent
-[no]truncate
-width columns         
-(help)                

version: MH 6.5 #132[UCI] (ihlpb) of Sun Jul  2 18:50:00 CDT 1989
options: [FOLDPROT='"0700"'] [ISI] [MHRC] [MORE='"more"']
         [MSGPROT='"0600"'] [RPATHS] [SYS5] [UUCP2DOM] [UUCPGATE]
         [TERMINFO] [MHMTS] [ATTPOST] [POSTDB]

Which is quite verbose.  But, all of the MH tools do this, so help is
right at hand if you forget the name of a switch.  A folder name always
has a '+' or an '@' (A not very well if at all documented feature) in
front to distinguish it from a list of messages.  A list of messages is
anything else on the command line.  I.e. "1-5", "unread", "old", "1 2
3" etc.  Any string that does not begin with a number is considered
to be a sequence name.

If you have the 'invoke this program when I get new mail' (forwarding
to a program) feature in your MTA, then the rcvstore(1) program can be
used to place each message into a folder as it arrives.  Otherwise, the
inc(1) program is used to move mail from your $MAIL file into a
folder.  The default folder is named 'inbox'.  When you log in, you
can type 'inc' to do this, or a shell command of the form

if [ -s $MAIL ]; then inc; fi

can be placed in your .profile.  As inc runs, it displays a single line
of information, known as an MH scan line.  The line contains the parts of
the message header and body that you typically need to see to know what
the message is about.  Once this is done, the scan command will redisplay
the contents of the folder when you need to.  Scan accepts sequence names
to limit the scope of its activities, so 'scan unread' or 'scan unseen'
can be used to just see the scan lines of the still UNSEEN mail.

These are some sample scan lines...

   4 #Feb 20   4318 dld@ihlpf.ATT.COM  a TeX example: patent study request form
   5  May 01    598 Mark Vasoll        Byron's Aviation EXPO '89  <<For your ca
   6  May 14   1793 dennis@iexist.att  <<To: ihlpb!gregg Gregg, I just remember
   7+#May 19   4329 Mark Vasoll        Thunderbirds and Blue Angels Schedules  
   8 #May 30   1134 Roland Stolfa      Re: The Pitts is back!!!!  <<Gregg, I am

To look at a message, you type show and the message number display beside
the message.  E.g. show 5.  If you wish to keep the message someplace
else, the refile command lets you do that.  I.e. 'refile 5 +planes'.
The '+' sign is necessary in front of the folder name to distinguish it
from a sequence name.  It is valid to type 'refile planes +planes', if
planes is a sequence name with at least one member message.

If you don't need the message any more, 'rmm' removes it (RM Message).

There are many more MH features and tools, but that is the basics.  The
MHL language is used to tell MH what a scan-line should contain, or
what your message should look like when you "show" it.  This allows
you to customize MH to do whatever you want.  There is a reminder service
that is built using MH (pick -before some-date -and -after some-date)
I have an alias called 'rem' that is aliased to 'mark -seq import'.  I
use it to mark important mail that needs to be taken care of pronto.  The
script called, import, produces a scan line for each such marked message
is all of my folders.

> But what really took the cake for me was the fact that if your mail is
> configured for MH, there's no other UA you can use-- you are stuck with MH.
> What if I told you I had an editor I'd like you to try but told you that
> if you used this editor, you can't use any other editor on files you edit
> using that editor.  This is how I see MH's folder format.  What saves MH
> is the fact that there is no "standard" (even proposed standards or RFCs)
> which discuss folder formats or anything similar.

The point is supposed to be that MH does everything that you need it
to.  That is why you would choose to use it.  Lets say you had to move
to another machine that did not have MH and you wanted to take your
mail folders with you.  The packf program is used to pack a folder into
a single file.  It could be altered to insert whatever information is
necessary to create most popular mail file formats.  MMDF is the
standard format that was chosen for MH output (^A^A^A^A around each
message).  It can read UUCP or MMDF format mail files though.  The
msh program puts all of the power of the MH tools into a program that
can deal with mail files, but the comment at the top of the program,

/* msh.c - The MH shell (sigh) */

conveys how the author and I feel about such a program.

> Upon further investigation, I learned that MH wasn't portable to any other
> unix besides BSD systems.  This may have changed lately -- I don't keep up
> with MH that much (my loss, I guess).  Is it true that MH still only talks
> to sendmail as its sole MTA?

MH has grown up a lot since you last saw it.  All of the BSD and VAX
dependencies have all (or nearly so) been removed.  It is running on the
u370 architecture here, under System V UN*X and it runs on many others.
I don't know how independent of sizeof(int) == sizeof (void *) it is, but
I think it is pretty safe (it uses <varargs.h> for whatever that is worth
to you).

> Bad excuse.  A good application (regardless of functionality; here we
> happen to be talking about MUAs) should have a "core" layer which makes
> the program function _independently_ of its user interface.  MH solved the
> problem by making each MH function a separate shell command.  Oy vey...
> You have to start a new process (fork!?), set up pipes, parse command line
> options, read init files (dot-files) and everything *for each MH command*.

Yes, it does a lot of start up work, I don't know how one would get around
that, given MHs current design.  I just don't like to here someone say that
a program is designed wrong because the features of the supporting OS make
it slow.  This is a fact of lige, but OS and HW designers need reasons to
start a new, and poor response from applications is a good motivation.

> MH isn't a "library" as you described, but rather a set of commands.  You
> build a "tool" in front of MH by doing a bunch of popen() calls, or system()
> calls, or whatever...  Don't you think that's rather inefficient/expensive?

NO NO NO!  MH does not require several processes to do something.  Typically
it is only two (the application and the pager, sometimes, it is only one,
that exec's the pager).  An MH tool IS made up of library routines, not
UNIX processes.  If you want something really complicated, then you write
a shell script to put the tools together.  There are many reasons why
this works out well.

One of my MH tools is a bunch of system() and popen() calls, but that was
done to make it easy on me.  In the future, I might change it to use the
library routines that each application that I call uses.

> Mush runs on a 80286 running xenix or a ATT PC and more -- can MH?

I would imagine so, providing the 64K data segment could handle MHs
static data, plus the malloc'd space for folder status information.
Certainly, large folders wouldn't work.

> Mush
> outperforms MH dramatically on large files.  For example, finding all
> messages from a particular author, that has a particular subject, that
> was sent (or delivered) between two dates from a folder with 500 messages
> takes about 6-10 seconds.  Or, deleting all messages that have been saved
> takes about 1 second.

Those are just numbers for mush, where are your MH numbers :-)  MHs speed
is directly related to the performance of the underlying system interface.
It is limited by this performance in most cases, not enhanced.  The fact
that people find it faster to use a single file and write lots of code to
keep up with the entities within the file says a lot for the work needed
on file I/O and the UN*X name space.

> I'd love to look at it again... But where does one get it?  Don't tell me
> I have to buy it :-).  Actually, there's nothing wrong with selling MH
> (or software, for that matter -- sorry, rms :-), it just means that I
> won't buy it due to my limited personal financial resources.

I seem to recall that it was on UUNET.UU.NET.  I have not really kept up
with the distribution though.  Post something to comp.mail.mh and ask
for information.

> As I said, there are good things about MH (altho I didn't get into them
> here, just note that I recognize them), but I feel that all the good things
> about MH can be dupicated more efficiently in a different way.

Recognize that effeciency comes in two forms though.  Computing effeciency,
as in the order of complexity of the algorithm, and the effeciency of the
operating system interfaces.  MH is limited my the latter, not necessarily
the former.  You chose to avoid the latter, by ignoring a lot of the things
that are supposed to be features of the OS.

-----
gregg.g.wonderly@att.com   (AT&T bell laboratories)
-- 
-----
gregg.g.wonderly@att.com   (AT&T bell laboratories)