Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!att!cbnewsc!gregg From: gregg@cbnewsc.ATT.COM (gregg.g.wonderly) Newsgroups: comp.mail.misc Subject: Re: MH verses the "all in one file" MUAs Message-ID: <1526@cbnewsc.ATT.COM> Date: 3 Jul 89 14:56:45 GMT References: <113567@sun.Eng.Sun.COM> Organization: AT&T Bell Laboratories Lines: 220 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 < 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 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)