gregg@cbnewsc.ATT.COM (gregg.g.wonderly) (07/03/89)
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)
wisner@mica.Berkeley.EDU (Bill Wisner) (07/04/89)
Clarification: In article <113567@sun.Eng.Sun.COM> argv%eureka@Sun.COM (Dan Heller) writes: >Greg points out that MH saves this info as well, but not in a header >which is visible to the user -- MH apparently filters this information >out when the message is displayed. Well, no. MH can be instructed to record when messages are replied to, forwarded, or redistributed, but it does not do so by default. Generally, it is the more advanced MH users that configure MH this way. The "normal" way for MH to display a message is just to print the whole thing out, including all headers. This includes the MH-inserted Replied: or Forwarded: headers. I, advanced MH user that I am, have set up a filter that removes these. I rather think that MH's method is more elegant than sticking the letter r in a Status: header. MH, big stud mailer, records the date and time of the reply and to whom the reply was sent. You get two lines of information for every reply you send. >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. Piffle. MH's packf command will take a bunch of messages and stick them together into an MMDF mail file. You can use any other UA that understands MMDF's file format. And speaking of religious wars, MMDF's format is superior to the standard UNIX mail format. >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? I have built MH on System V machines, and on machines running MMDF and Smail3.1. It works quite well on each. >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? Look at an MH source tree sometime. There most certainly is a library of basic MH functions, which is used to build the MH user commands (and can be used in your own MH tools). >> using MH at universities are not going to have high speed CPUs. MH's >> MH's >> executables average about 200-300K here, and I imagine they are similar >> in size elsewhere. Eh wot? 90-100K here for inc, scan and show (the three most oft-used MH commands). >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. An "official" distribution can be found on louie.udel.edu in the portal/ directory. (No affiliation with the California USENET site.) >As you said, MUAs are as religious as using different editors -- you're >never going to convince an emacs user to use vi, and chances are unlikely >that you're going to convert an MH user to use Mush (altho there are some >cases where this has happened :-). Well, I was a mush user until I came across MH.. Bill Wisner wisner@mica.berkeley.edu ucbvax!mica!wisner I'm not the NRA either.
argv%eureka@Sun.COM (Dan Heller) (07/05/89)
In article wisner@mica.Berkeley.EDU (Bill Wisner) writes: > Clarification: > In article <113567@sun.Eng.Sun.COM> argv%eureka@Sun.COM (Dan Heller) writes: > >Greg points out that MH saves this info as well, but not in a header > >which is visible to the user -- MH apparently filters this information > >out when the message is displayed. > > The "normal" way for MH to display a message is just to print the whole > thing out, including all headers. This includes the MH-inserted Replied: > or Forwarded: headers. Remember the reason this whole issue came up. Someone complained/asked about the Status: header and Karl replied by saying that it's "bogus" for the UA to add these headers to messages. Yet in reality, that is exactly what MH is doing, so he defeats his own argument. Nevertheless, I never agreed that this was a "bad thing." Au contraire, mon frere. Not only do I see it as the only option (no other way to do it), I also think it's a good thing to do. Retaining information about replied info and saved info, etc, is important and retaining that information anywhere else besides the message headers is poor design (which is why everyone implements it that way). > I, advanced MH user that I am, have set up a > filter that removes these. The filter that you chose to remove the display of those headers when your message is displayed is also available to the Mail/Mush paradigm using the ignore command. > MH, big stud mailer, records the date and time of > the reply and to whom the reply was sent. You get two lines of information > for every reply you send. I will concede to the fact that MH's method of storing replied-to information is better than Mush's. However, Mush will continue to use the Status: header because this header is useful for other reasons. For example, you can sort your mail by the status of a message (e.g. place all replied to messages next to one another, group all new/unread messages, saved messages, etc...). It takes vitually no user time at all to do this because Mush doesn't have to scan message headers in order to determine the status of the message -- when the folder is loaded, the status is stored in internal data structures and retained as long as the folder is open. > >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. > > Piffle. MH's packf command will take a bunch of messages and stick them > together into an MMDF mail file. You can use any other UA that understands > MMDF's file format. And speaking of religious wars, MMDF's format is > superior to the standard UNIX mail format. I don't want to start a religioous war on this (and if anyone cares to continue this conversation, start a new message; don't reply to this one and discuss this issue). But the simple fact that ^A is not a printable character means that mail MTAs are going to have a major problem in mailing that message to someone. You can't mail MMDF folders without a probable headache. Secondly, why a message separator at the start *and* one at the end of a message. Basically, you have two sets of ^A's that are adjacent to one another. What can you stick between them? Hmmm... maybe that's a good place to put "status" information about a message... hey, maybe they have something there :-). At any rate, the only problem I have with that scheme is that the text is non-printable. I don't advocate using "From " either. I think the best thing to do would be to come up with something new, but whatever it is won't be compatible with most of the current folder formats that are out there. Compatibility, unfortunately, is a strong argument for leaving things be. > Well, I was a mush user until I came across MH.. :-D dan <island!argv@sun.com> ----- My postings reflect my opinion only -- When on the net, I speak for no company.
schaefer@ogccse.ogc.edu (Barton E. Schaefer) (07/05/89)
Where have all the References: gone? Let's hope these attributions are correct ... In article <1518@cbnewsc.ATT.COM> (I think) gregg@cbnewsc.ATT.COM (gregg.g.wonderly) writes: } Okay, here's some questions to think about. What does } mush/elm/mail/whatever not do that MH already does? How much effort will } it take to add those features (if they are desireable)? Aye, there's the rub. I've only used MH a little, but an (admittedly brief) perusal of the "Rand MH Message Handling System" document in the 4.3 BSD manual pages reveals that of the 6-8 things MH does that mush does not%, approximately 5 are things that mush intentionally avoids. ___________ % The counts vary depending on your definition. Mush handles *almost* all of the basic MH functions, and has hooks to attach most of the other functionality. Mush *could* handle virtually everything MH provides. It has the most trouble with "message sequences" and having them persist across exit/restart. ___________ } By the time } you have done that, what will have been added to MH that the other MUAs } then won't have? 50-60 separate executable programs, each with it's own UNIX-style man entry. :-) :-) (gregg.g.wonderly continues): } Now for the 'slow to use' part. The fact of the matter is that most people } using MH at universities are not going to have high speed CPUs. MH's } executables average about 200-300K here, and I imagine they are similar } in size elsewhere. This being the case, MH can be slow on a machine with } limited resources. But so is every other largish program I have seen. In article <113567@sun.Eng.Sun.COM> island!argv@sun.com (Dan Heller) responds: } Mush averages about 100K and provides many features that MH has "as it } turns out." That is, I didn't design mush to be MH compatible, it just } so happened that some commands and features are very similar. With suntools, } the binary is bigger -- about 1 MEG or so depending on the version of sunview } or sunwindows you compile with. Without the curses interface, it's smaller. Just to keep Dan honest, Mush actually runs about 250K on BSD systems with the curses interface. MH's executables (on our Sequent) average just over 100K, ranging from a minimum of about 75K to a max of almost 300K. The difference here is not in the size of the executables but the number of them. There is a single mush. There are 30 executables in mh/bin and 11 more in mh/lib. (MH, like GNU, is not for small systems.) I don't know how the vmh and msh interfaces work, but if they fork/exec one or more of those 30 executables for every command, they've gotta have a lot more overhead than any single program. And even if vmh/msh avoid fork/exec, running all those individual programs from the [cbk?]sh, which seems to be the preferred way of using MH, does NOT avoid it. In article <1526@cbnewsc.ATT.COM> gregg@cbnewsc.ATT.COM (gregg.g.wonderly) writes: } Several people make the statement that MH has some 'poor design schemes', } can you elaborate on those that you feel make it deficient? It's a matter of point of view. Obviously the designers of MH did not feel that their design was deficient, and you may not either. I have to admit that they followed admirably the "UNIX philosophy" of using a lot of small, specialized tools strung together to accomplish a larger task. The question is whether that is the best way to approach this particular problem. (No UNIX Philosophy wars, please.) MH is very flexible, and if you are a C or shell hacker you can probably make it do amazing things. There are a number of very impressive things (based on my quick look at the manual) that it% can do even without new programs hooked onto it. But how simply can the average person custom- ize MH to suit his personal preferences? And how many separate programs does he need to know how to configure to accomplish that? One last question about MH: How easy is it for Joe Random User to install MH in his own directory tree and use it in preference to whatever his system managers have decided is "best"? ____________ % Perhaps MH should actually be referred to in the plural, as "they". :-) ____________ (Dan, from back in <113567@sun.Eng.Sun.COM> again): } 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*. (gregg): } 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 life, but OS and HW designers need reasons to } start a new, and poor response from applications is a good motivation. Which came first, MH or UNIX? You can't blame UNIX for making MH slow. MH was designed to run under UNIX. If the designers of MH had felt that the speed of UNIX "features" was a problem, they could have designed around them. They chose not to -- which is fine, but you can't then turn around and say "UNIX did it!" when people complain. Now we return to the original Status: header discussion: In article <WISNER.89Jul3114848@anableps.berkeley.edu> wisner@mica.Berkeley.EDU (Bill Wisner) writes: } Clarification: } } The "normal" way for MH to display a message is just to print the whole } thing out, including all headers. This includes the MH-inserted Replied: } or Forwarded: headers. In <113637@sun.Eng.Sun.COM> island!argv@sun.com (Dan Heller) comes back: } Remember the reason this whole issue came up. Someone complained/asked } about the Status: header and Karl replied by saying that it's "bogus" } for the UA to add these headers to messages. Yet in reality, that is } exactly what MH is doing, so he defeats his own argument. A little referential confusion there. Bill defeats Karl's argument. Sort of. } Nevertheless, } I never agreed that this was a "bad thing." [Redundant French deleted.] } Not only do I see it as the only option (no other way to do it), I also } think it's a good thing to do. One would think that this puts the issue to rest. However, Dan then procedes to shoot himself in the foot (or at least the toes): } I will concede to the fact that MH's method of storing replied-to } information is better than Mush's. However, Mush will continue to } use the Status: header because this header is useful for other reasons. } For example, you can sort your mail by the status of a message (e.g. } place all replied to messages next to one another, group all new/unread } messages, saved messages, etc...). It takes vitually no user time at } all to do this because Mush doesn't have to scan message headers in order } to determine the status of the message -- when the folder is loaded, } the status is stored in internal data structures and retained as long } as the folder is open. Taking devil's advocate here, if the status is stored in internal data structures, what difference does it make whether there is a Status: in the folder? The internal status could be assembled based on any set of headers in the message. The question is, what is the real objection to Status: headers? Their mere presence, or that they store information in an encrypted form that is of little use without the help of the MUA in decrypting it? But returning now to the guts of the folder-format argument, Bill respnds to Dan's complaint about MH incompatibility with other MUAs: } Piffle. MH's packf command will take a bunch of messages and stick them } together into an MMDF mail file. You can use any other UA that understands } MMDF's file format. And speaking of religious wars, MMDF's format is } superior to the standard UNIX mail format. The "superior format" argument has gone off in another thread, but I wanted to make one comment. Providing a conversion utility is not the same thing as providing compatibility. MH doesn't care, because it is supposed to do everything (I believe "big stud mailer" was the term :-). -- Bart Schaefer "And if you believe that, you'll believe anything." -- DangerMouse CSNET / Internet schaefer@cse.ogc.edu UUCP ...{sequent,tektronix,verdix}!ogccse!schaefer
karl@giza.cis.ohio-state.edu (Karl Kleinpaste) (07/06/89)
argv%eureka@Sun.COM writes:
Remember the reason this whole issue came up. Someone complained/asked
about the Status: header and Karl replied by saying that it's "bogus"
for the UA to add these headers to messages. Yet in reality, that is
exactly what MH is doing, so he defeats his own argument.
No, not quite. I said that it's gross. More precisely, grotesque, I
suppose. I still think so - anything that has to keep hacking on my
mail file(s) after delivery (regardless of whether it's "all in one
file" or done piecemeal in individual message filess) is doing
something grotesque. I don't use MH, so I can hardly be accused of
defeating my own argument. My UA is GNUS for both mail and news; what
minimal status I require is maintained in my .newsrc.
--Karl
PS- So who's singing about this anyway? "verses?" Oh, you meant
"versus..."msir@uhura.cc.rochester.edu (Mark Sirota) (07/06/89)
In article <1518@cbnewsc.ATT.COM> gregg@cbnewsc.ATT.COM (gregg.g.wonderly) writes: > I had a personal reply from my original article that stated this >> And MH is huge, chews up disk space and inodes, and is hard to learn and >> slow to use. That was me. The huge issue was covered by Dan. The distribution is enormous; generally too big for anyone but a system administrator to handle. What if some random user would like to use it, but it's not installed on the system? You glossed over the "chews up disk space" issue, here. Remember that every file size is rounded up to the nearest blocksize, which is usually 1024 bytes. There are several members of the system staff here who use MH and store hundreds of messages each, thereby chewing up disk space (and inodes) in a disastrous fashion. Sure, they can packf their folders every once in a while, but there's that added effort again (see below). The "slow to use" comment was not meant to refer to the speed of the command execution, but the effort required to get anything done. There are two parts to this. With any MUA, you have to first customize it, then use it. In both cases, I claim that MH is slower and more complicated than Mush. For example, suppose I want to reply to a letter. When I do so, I want to include the letter I'm replying to with nice headers around it, and use the editor of my choice, and add my signature to the end of it if appropriate. The customization phase with MH seems to involve setting up a good reply editor. It seems that I need to write a little shellscript using sed(1) or awk(1), along with "mhl" and a formfile, which sets up the message with the included message and my signature, and then calls my favorite editor ($VISUAL). That is not an easy task for a novice MH user, particularly if they're a novice UNIX user. (sed? awk? pipes? $VISUAL? shellscripts?) Note that I am only a psuedo-advanced MH user, so there might be easier ways to do this, but they seem to be either complicated or hard to find. In Mush, I set a couple of variables in my .mushrc, like autoinclude, autoedit, autosign, and pre_indent_str. (Actually, I don't do all these, things, since I don't always want to include the letter or my signature, or edit it automatically. I can choose to do that on the fly, by specifying options to the "reply" command, like "reply -i -e".) Note that this is just an example. I feel it illustrates the point. In article <WISNER.89Jul3114848@anableps.berkeley.edu> wisner@mica.Berkeley.EDU (Bill Wisner) writes: > Well, I was a mush user until I came across MH.. Well, I was an MH user until I came across Mush. -- Mark Sirota - University of Rochester, Rochester, NY Internet: msir@cc.rochester.edu Bitnet: msir_ss@uordbv.bitnet UUCP: {decvax,harvard,ames,rutgers}!rochester!ur-cc!msir
wisner@mica.Berkeley.EDU (Bill Wisner) (07/06/89)
In article <2425@ur-cc.UUCP> msir@uhura.cc.rochester.edu (Mark Sirota) writes: >The customization phase with MH seems to involve setting up a good reply >editor. It seems that I need to write a little shellscript using sed(1) or >awk(1), along with "mhl" and a formfile, which sets up the message with the >included message and my signature, and then calls my favorite editor >($VISUAL). That is not an easy task for a novice MH user, particularly if >they're a novice UNIX user. (sed? awk? pipes? $VISUAL? shellscripts?) I shell alias and a one-line MHL template. That's it. To wit: alias repli 'repl -filt mhl.repl' And, in ~/Mail/mhl.repl: body:component="> ",offset=0 Obscure, yes, but not nearly as difficult as you make it look. And though MH may have a rough learning curve, there are many MH stUds who are glad to help. Bill Wisner wisner@mica.berkeley.edu ucbvax!mica!wisner I'm not the NRA either.
argv%eureka@Sun.COM (Dan Heller) (07/06/89)
In article <3562@ogccse.ogc.edu> schaefer@ogccse.UUCP (Barton E. Schaefer) writes: > Where have all the References: gone? Let's hope these attributions are > correct ... well, when I followup to an article with too many references, rn dies. I don't know about anyone else, but I have to remove a couple references in order for rn to work. [me] > } Nevertheless, > } I never agreed that this was a "bad thing." [Redundant French deleted.] > } Not only do I see it as the only option (no other way to do it), I also > } think it's a good thing to do. > > One would think that this puts the issue to rest. However, Dan then > procedes to shoot himself in the foot (or at least the toes): > > } However, Mush will continue to > } use the Status: header because this header is useful for other reasons. > Taking devil's advocate here, if the status is stored in internal data > structures, what difference does it make whether there is a Status: in > the folder? Because Mush advertises itself to be backwards compatible with Mail as much as possible. And Mail uses the Status: header. Thus, mush will continue to do so. :-| One of the [perhaps poor] selling points of Mush is that it can look just like Mail if configured that way. Too many times people tell me that they'd like to install mush at their site, but everyone uses Mail and they don't want to hinder their productivity by introducing something new. Mush comes with a Mailrc file that will make mush look enough like Mail that most [naive] users can't tell the difference. However, it can also be configured to look like vi or emacs in the "curses mode" or like csh in the "tty mode". The suntools mode doesn't look like sun's mailtool because it was written before mailtool was (sunOS 2.0). dan <island!argv@sun.com> ----- My postings reflect my opinion only -- I represent no company's opinions.
allbery@ncoast.ORG (Brandon S. Allbery) (07/07/89)
As quoted from <113567@sun.Eng.Sun.COM> by argv%eureka@Sun.COM (Dan Heller): +--------------- | In article gregg@cbnewsc.ATT.COM (gregg.g.wonderly) writes: | > From article <113461@sun.Eng.Sun.COM>, by argv%eureka@Sun.COM (Dan Heller): | > I had a personal reply from my original article that stated this | > >And MH is huge, and chews up disk space and inodes, and hard to learn, and | > >slow to use. | | 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 +--------------- Eh wot? Not really; certainly, it needs better documentation, but that is solvable. +--------------- | 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. +--------------- "What if I told you I had a {word processor/spreadsheet/database}...." I'm not convinced that you have an argument, when it comes to the real world. +--------------- | 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? +--------------- Tell it to ncoast, which is AT&T System *III* (_not_ System V!). Tell it to telotech, which has a mini-SMTP program to let MH in "sendmail" mode talk to an ordinary mailer. Tell it to all the sites that use MMDF, for that matter. +--------------- | > That, I cannot dispute. However, I take up the argument | > that this is not a problem, but rather a feature. If you have ever written | > an MH tool (I have written 4 to date), then you know how powerful and easy | > to use the library routines are. | | 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*. +--------------- Two different issues. MH has an extensive library which can be used to build new MH tools in C. It is also a set of executables which can be used to build new commands as shell scripts. And I find that latter ability to be extremely useful. +--------------- | 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? +--------------- Flat-out *wrong*. If you're programming in C, you use the MH library. The executables are used for a *shell* toolkit; you are *not* expected to use system() or popen() from a C program to talk to it! +--------------- | design has been completed. The point is, Mush is a library of function | calls, not a set of unix commands. +--------------- See above. +--------------- | In mush, if you can type "help", you've got it just about licked.. | Of course, if you know how to hit "?" that works, too. As simple | as you seem to think it is to type "inc", etc..., I never knew to | do that when I first learned MH. Despite the doc! +--------------- Awwww. Because I can't rewrite the shell to automatically provide MH help, MH is worthless. Frankly, a simple MH help command is trivial to write; call it "mh-help" and you've got it made. +--------------- | > Give MH a try. If you hate it, throw it away (or even burn the tape in | 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. +--------------- Egads. $75 for the tape from UC Irvine, or FTP it from many Internet archive sites. *Now* you're digging. ---- I personally use MH because, unlike you (apparently), I find it *extremely* *useful* to be able to access messages as files and use MH commands in pipelines (*anywhere* in pipelines). Without even having to learn a new shell or pseudo-shell. Then I can write shell scripts to do things for me. I find it difficult to imagine mush being implemented in such a way that I can change my scripts to use it. (Don't bother suggesting that I won't "need" the scripts under mush; they're generally not the kind of thing that can reasonably be executed from a mailer. I tend to use MH as a sort of file cabinet which can be used to transfer stuff between Unix commands (and Unix systems) and storage "on the fly".) Other people will have other needs, and won't necessarily need (or want) MH. Fine. But suggesting that MH's implementation isn't useful in and of itself isn't acceptable. ++Brandon -- Brandon S. Allbery, moderator of comp.sources.misc allbery@ncoast.org uunet!hal.cwru.edu!ncoast!allbery ncoast!allbery@hal.cwru.edu Send comp.sources.misc submissions to comp-sources-misc@<backbone> NCoast Public Access UN*X - (216) 781-6201, 300/1200/2400 baud, login: makeuser
gregg@cbnewsc.ATT.COM (gregg.g.wonderly) (07/07/89)
From article <WISNER.89Jul5132757@anableps.berkeley.edu>, by wisner@mica.Berkeley.EDU (Bill Wisner): > I shell alias and a one-line MHL template. That's it. To wit: > > alias repli 'repl -filt mhl.repl' > > And, in ~/Mail/mhl.repl: > > body:component="> ",offset=0 Simply putting the line repl: -filt mhl.repl makes it always happen. If you extend the file to look more like body:component="> ",offset=0 : :----- :gregg.g.wonderly@att.com (AT&T Bell Labs or ihlpb!gregg) and you get the signature line as well. Remember how Brandon always has replies that look like +------------------------------ + original message text +------------------------------ He probably uses something like :+--------------------- body:component="+ ",offset=0 :+--------------------- as his filter. > Obscure, yes, but not nearly as difficult as you make it look. And though MH > may have a rough learning curve, there are many MH stUds who are glad to > help. It really does not hurt to ask! There is a comp.mail.mh group, and this precise topic has gone by at least 3 times in the past 6 months (which says something for the MHL documentation or lack thereof). -- ----- gregg.g.wonderly@att.com (AT&T bell laboratories)
argv%eureka@Sun.COM (Dan Heller) (07/07/89)
It seems that once again, the pace of usenet has affected this discussion. Bill Wisner's previous reponse to my article has completely lost scope of the discussion. The note appears hostile, so I just assume drop that end of the debate. However, Brandon is several articles behind and makes some unfortunate misconceptions about my intent... such is the case whenever "religion" comes into any peaceful discussion. :-) (note: BIG smile) In article allbery@ncoast.ORG (Brandon S. Allbery) writes: > As quoted from <113567@sun.Eng.Sun.COM> by argv%eureka@Sun.COM (Dan Heller): > > | 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? See? a *question* not a *statement*. This is the major problem with religious arguments. Yet, it generates responses like this: > Tell it to ncoast, which is AT&T System *III* (_not_ System V!). > Tell it to telotech, which has a mini-SMTP program to let MH in "sendmail" > mode talk to an ordinary mailer. > Tell it to all the sites that use MMDF, for that matter. In short -- relax. > I personally use MH because, unlike you (apparently), I find it *extremely* > *useful* to be able to access messages as files and use MH commands in > pipelines (*anywhere* in pipelines). Without even having to learn a new > shell or pseudo-shell. Then I can write shell scripts to do things for me. > I find it difficult to imagine mush being implemented in such a way that I > can change my scripts to use it. You can do just about the same thing in mush. The syntax may be a little different than what you're used to with your csh scripts, but because mush is built on the csh paradigm, chances are you don't have to learn anything new. In fact, I know many people who source their .cshrc from their .mushrc so they can retain all their csh aliases, and stuff. This isn't entirely portable over, but conversion is simple enough that one script can support both mush and csh. In fact, just about everything you're used to doing in MH can probably be done in mush. The upside is that mush is much faster at it. The downside is that your scripts might have to be modified minimally. And now, the apitome of a religious argument: Putting words into one's mouth. > But suggesting that MH's implementation isn't useful in and of > itself isn't acceptable. I -never- said or imply that MH wasn't useful. On the contrary, I've stated several times that MH is a very good *and* useful program. There is a lot of good things about it. My point was that I don't necessarily like it's design implementation and feel that the same functionality could be done more efficiently using another design methodology. dan <island!argv@sun.com> ----- My postings reflect my opinion only -- not the opinion of any company.
jos@idca.tds.PHILIPS.nl (Jos Vos) (07/07/89)
In article <13801@ncoast.ORG> allbery@ncoast.ORG (Brandon S. Allbery) writes: >As quoted from <113567@sun.Eng.Sun.COM> by argv%eureka@Sun.COM (Dan Heller): >+--------------- >| 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? >+--------------- > >Tell it to ncoast, which is AT&T System *III* (_not_ System V!). Tell it to me. I'm probably dreaming until now. Nice dream with System V.2, V.3.0, V.3.1 and V.3.2 systems... (pure MH 6.6 Ok. I made some *small* (really!) adaptions which I partly did send to bug-mh already, and partly will send in the next weeks. (E.g. supporting V.3 directory access routines.) Maybe they will be included in the patch promised in comp.mail.mh. The patches for letting MH work with an available TCP/IP implementation on System V systems are planned to be done in the next weeks. I already investigated the problem areas and I think it will be easy. -- -- ###### Jos Vos ###### Internet jos@idca.tds.philips.nl ###### -- ###### ###### UUCP ...!mcvax!philapd!jos ######
njs@scifi.UUCP (Nicholas J. Simicich) (07/09/89)
The babyl format that GNUemacs RMAIL uses also saves information of that sort (answered, forwarded, filed, unseen, and user defined tags) in an internal format between the messages. It doesn't add headers, and certainly doesn't transmit tags or status with copies of the message. -- Nick Simicich --- uunet!bywater!scifi!njs --- njs@ibm.com (Internet)
wisner@mica.Berkeley.EDU (Bill Wisner) (07/10/89)
In article <681@scifi.UUCP> njs@scifi.UUCP (Nicholas J. Simicich) writes: >The babyl format that GNUemacs RMAIL uses also saves information of >that sort (answered, forwarded, filed, unseen, and user defined tags) >in an internal format between the messages. It doesn't add headers, >and certainly doesn't transmit tags or status with copies of the >message. Right. And it does so quite efficiently, too. Why, just look at this RMAIL file. And be sure to notice that some of the headers are duplicated. BABYL OPTIONS: Version: 5 Labels: Note: This is the header of an rmail file. Note: If you are seeing it in rmail, Note: it means the file has no messages in it. ^_^L 1,, Received: from anableps.Berkeley.EDU by mica.berkeley.edu (4.0/1.30) id AA02933; Sun, 9 Jul 89 14:38:51 PDT Message-Id: <8907092138.AA02933@mica.berkeley.edu> To: wisner Subject: babyl stinks Date: Sun, 09 Jul 89 15:38:44 PDT From: Bill Wisner <wisner> *** EOOH *** To: wisner Subject: babyl stinks Date: Sun, 09 Jul 89 15:38:44 PDT From: Bill Wisner <wisner> This message being sent to demonstrate the incredible wastefulness of babyl. ^_
bsa@telotech.UUCP (Brandon S. Allbery) (07/16/89)
Re: BABYL format duplicating headers It's only wasteful from one viewpoint. The other viewpoint is that, unlike MH's "mhl" filter and mailx's (Mail's, for Berzerkers) "ignore" functionality, BABYL applies header prettifying *once* and saves it, simplifying formatting at display time. This can make a big difference to someone reading mail: compare the time for RMAIL mode to display a message, compared to MH-E with mhl filtering enabled. BABYL fulfills a different design goal; comparing its header storage format to MH or mailx or mush, etc. is comparing apples and oranges. ++Brandon
argv%eureka@Sun.COM (Dan Heller) (08/08/89)
I am moving this discussion to comp.mail.misc because it doesn't have anything to do with headers anymore. The reason this all started was that someone took notice of the Status: header present in Mail-based MUA's. Mail, Elm (I guess), Mush, mailx, ... all do this: use the Status: header to save information about whether the message is new, unread.. Mush also uses the status header to store info about whether the message has been saved, replied to, and so on. Greg points out that MH saves this info as well, but not in a header which is visible to the user -- MH apparently filters this information out when the message is displayed. The first part of this message contains the preliminary discussion between us. The latter part of the message actually discusses the drawbacks of MH and a few comments about Mush. People who are interested in continuing a discussion about good MUA development as well as hardline MH users are encouraged to read this message and participate in the discussion. Sorry if the preliminary dialog is hard to follow -- I edited it to make it clear about the direction the discussion is going. In article gregg@cbnewsc.ATT.COM (gregg.g.wonderly) writes: > From article <113461@sun.Eng.Sun.COM>, by argv%eureka@Sun.COM (Dan Heller): > > In article gregg@cbnewsc.ATT.COM (gregg.g.wonderly) writes: > >> And most of us use the appropriate MHL formats and filters to have them > >> stripped later. Note that MHs repl(1) command (for replying to a message) > >> will allow you to reply multiple times. The Replied headers are stripped > >> from the resulting message by the time you see it in the editor to add > >> your reply. > > > > There -are- other stupid UA's out there that > > don't do the right thing [referencing how mail is replied to]. But, > > that has nothing to do at all with how a mail folder is stored. It is > > incorrect to make the following statement: > > > >> people who continue to implement MUAs that use a single file for > >> storing all messages seem to continue to replicate all the things that > > note that I said SEEM...^^^^ Yes, you said "seem", but the implication is clear :-). Nevertheless, I'm willing to let it go. > > The reason [your statement] is incorrect is because your assumption is that it is > > the single-file-folder "feature" that makes the program "bad." > > A well written/designed UA should [try to] make it as transparent as > > possible about the method for how mail is stored. You are making a > > grave mistake by attributing the storage method utilized by a UA to the > > bugs or implementation (design) features of that UA. If you think that > > MH's "features" are a result of the fact that it's folder storage method > > is attributed to the fact that it stored messages on a file-per-message > > format, you are mistaken. > > I did not say anything about the merits of either method. What I said > was that I have yet to see a "all messages in the same file" UA that > does anything but what the others from the past do. People are > spending a lot of time reproducing PD replacements for MUAs that don't > do anything really that different and useful. You later admit that you haven't used anything else but MH for the past 5 years, so this statement doesn't carry much weight. Nevertheless, your observation is somewhat accurate: Most UAs developed today are limited in either functionality (feature-list) or tend to be ill-designed and are desitined to make the same mistakes as those that preceded them. With these problems in mind, I designed Mush for the purpose of avoiding these problems while taking advantage of other issues (described later). > Okay, here's some questions to think about. What does > mush/elm/mail/whatever not do that MH already does? How much effort will > it take to add those features (if they are desireable)? By the time > you have done that, what will have been added to MH that the other MUAs > then won't have? 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. > I don't mean to start any wars on MUAs. I am just trying to see if the > individuals doing the work are thinking about were they are going. It > is a real waste of talent to continually play catchup, always adding the > feature that you don't have yet. Believe me, we are aware of what we're doing and are continuing in a well defined direction. There are definite problems with using a Mail-method folder format, but there are an equal number of problems with using the MH-method. One of the major advantages to using the Mail-based folder storage method is that it is backwards compatible with [most] other Mail applications (I address this issue again later). > I had a personal reply from my original article that stated this > >And MH is huge, and chews up disk space and inodes, and hard to learn, and > >slow to use. 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. 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. 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? > That, I cannot dispute. However, I take up the argument > that this is not a problem, but rather a feature. If you have ever written > an MH tool (I have written 4 to date), then you know how powerful and easy > to use the library routines are. 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*. 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? Mush hasn't quite been set up to be totally independent of its user inter- face, but it is so close that it took me effectively two weeks to build the curses interface on it. It also has a suntools interface and a tty (csh-like) shell interface. Building a new front end of Mush is in fact very easy -- it'll even be easier once the implementation of its final design has been completed. The point is, Mush is a library of function calls, not a set of unix commands. > Putting this > aside, if you can type the strings > > inc > scan unseen (or scan unread) > show > rmm > refile > > you can use MH without any real difficulty. In mush, if you can type "help", you've got it just about licked.. Of course, if you know how to hit "?" that works, too. As simple as you seem to think it is to type "inc", etc..., I never knew to do that when I first learned MH. Despite the doc! > Now for the 'slow to use' part. The fact of the matter is that most people > using MH at universities are not going to have high speed CPUs. MH's > executables average about 200-300K here, and I imagine they are similar > in size elsewhere. This being the case, MH can be slow on a machine with > limited resources. But so is every other largish program I have seen. Mush averages about 100K and provides many features that MH has "as it turns out." That is, I didn't design mush to be MH compatible, it just so happened that some commands and features are very similar. With suntools, the binary is bigger -- about 1 MEG or so depending on the version of sunview or sunwindows you compile with. Without the curses interface, it's smaller. Mush runs on a 80286 running xenix or a ATT PC and more -- can MH? 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. > Give MH a try. If you hate it, throw it away (or even burn the tape in 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. > But at least try it. MUAs are really a religous issue, so I will > not press any harder. I just needed to make some arguments against some > of the bad things that people are saying about MH. 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. Future plans for Mush include supporting MH style folders, news, several inter- face enhancments (more csh-like features) and performance modifications. As you said, MUAs are as religious as using different editors -- you're never going to convince an emacs user to use vi, and chances are unlikely that you're going to convert an MH user to use Mush (altho there are some cases where this has happened :-). > gregg.g.wonderly@att.com (AT&T bell laboratories) dan <island!argv@sun.com> ----- My postings reflect my opinion only -- When on the net, I speak for no company.
abc@ecrcvax.UUCP (Andy "Burger King" Cheese) (08/14/89)
>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 also talks to MMDF2 ------------------------------------------------------------------------------- Andy Cheese European Computer-Industry Research Centre GmbH Arabellastrasse 17 D-800 Muenchen 81 West Germany ...!pyramid!ecrcvax!abc
loverso@Xylogics.COM (John Robert LoVerso) (08/15/89)
In article <113567@sun.Eng.Sun.COM> island!argv@sun.com (Dan Heller) writes: > 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? Are you sure? I know MH handled MMDF as early as MH.5 (1985), and I think the MH.3 from the 4.2BSD user contributed software tape did, too. Anyway, I don't remember anything in MH that forced it to a sole MTA. > 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*. Actually, I *like* that sort of interface. All you really need is a real machine to run it on. Real multiprocessors (Encore, Sequent) make heavy use of pipes inexpensive (and very fast). When I last used MH, however, all I had was a 750. Blech. MH.6 (which had just come out then) was slow slow slow. MH.3, which I had originally used, was fast and simple. Its just that somewhere between the two, 5 years of new features were added... > Mush hasn't quite been set up to be totally independent of its user inter- > face, but it is so close that it took me effectively two weeks to build > the curses interface on it. And the whole reason I use Mush today is that the curses interface is a very convenient way to read mail fast. It lets me browse my (substantial) incoming mail and junk the stuff I don't want. At the very least, I strongly recommend it to anyone still using the crufty UCB Mail (aka mailx), with that gastly code to rewrite headers when replying, etc... John
fuat@cunixc.cc.columbia.edu (Fuat C. Baran) (08/16/89)
In article <113567@sun.Eng.Sun.COM> island!argv@sun.com (Dan Heller) writes: >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. I am one of the authors of MM, a MUA written here at Columbia University, based on the TOPS-20 (DEC-20) program MM. One of the future Beta releases of MM will have support for MH format mail folders. (Currently MM can only read/write mbox, mail.txt and babyl format files, but in order to experiment with performance improvements (large files take time to read/write) we are working on MH format). Also, with the addition of a few "bboard" commands, we plan on giving our users a simpler interface to netnews. [Note: MM is still in Beta test, though it is used at quite a few places on a daily basis. MM uses CCMD (our version of the TOPS-20 COMND Jsys, for those of you familiar with DEC20's) to provide command/keyword completion, help on '?', etc. For more info send mail to info-mm-request@cunixc.cc.columbia.edu.] >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? This is true for MM as well, though one of our beta testers is working on a zmailer interface, and it should be fairly easy to make it use other MTA's in the future (especially after a bit of cleanup in the code). >As you said, MUAs are as religious as using different editors -- you're >never going to convince an emacs user to use vi, and chances are unlikely >that you're going to convert an MH user to use Mush (altho there are some >cases where this has happened :-). Yup. :-) One of our main motivations in writing MM is that we had a large user population migrating from DEC20's to UNIX machines, and MM was one of the top things they wanted. --Fuat -- INTERNET: fuat@columbia.edu U.S. MAIL: Columbia University BITNET: fuat@cunixc.cc.columbia.edu Center for Computing Activities USENET: ...!rutgers!columbia!cunixc!fuat 712 Watson Labs, 612 W115th St. PHONE: (212) 854-5128 New York, NY 10025