shprentz@bdmrrr.bdm.com (Joel Shprentz) (09/23/87)
Can anyone comment on how Mush, the mail user's shell just posted to comp.sources.unix, compares with Elm or MH? -- Joel Shprentz Phone: (703) 848-7305 BDM Corporation Uucp: seismo!bdmrrr!shprentz 7915 Jones Branch Drive shprentz@bdmrrr.bdm.com McLean, Virginia 22102
david@ms.uky.edu (David Herron -- Resident E-mail Hack) (09/24/87)
In article <905@bdmrrr.bdm.com> shprentz@bdmrrr.bdm.com (Joel Shprentz) writes: >Can anyone comment on how Mush, the mail user's shell just posted to >comp.sources.unix, compares with Elm or MH? I've not ever used ELM or MH but have looked at them enough to know their features. And we've done a little bit of work on Mush to run it under MMDF (so that we can evaluate it) ... At the moment our problem with it is that 1. It wants to do routing ... That feature can be turned off, but still it doesn't belong in a User Agent. 2. It doesn't follow RFC822 closely. (I don't know the details on this, but probably will eventually ...) (Also, it core-dumped with one message that had a To: line that went for about 30 lines ... there weren't any syntax errors, but it did go for a looooong time ... core-dumping isn't a very friendly thing to do). Other than that it looks like a nice program. >Joel Shprentz Phone: (703) 848-7305 >BDM Corporation Uucp: seismo!bdmrrr!shprentz ^^^^^^ Sure this is right? >7915 Jones Branch Drive shprentz@bdmrrr.bdm.com >McLean, Virginia 22102 -- <---- David Herron, Local E-Mail Hack, david@ms.uky.edu, david@ms.uky.csnet <---- {rutgers,uunet,cbosgd}!ukma!david, david@UKMA.BITNET <---- <---- Je parle francais comme une vache espagnole.
bill@trotter.usma.edu (Bill Gunshannon) (09/25/87)
In article <905@bdmrrr.bdm.com>, shprentz@bdmrrr.bdm.com (Joel Shprentz) writes: > Can anyone comment on how Mush, the mail user's shell just posted to > comp.sources.unix, compares with Elm or MH? > I can't comment on MUSH yet because I am missing parts 7-12 but I can tell you that although ELM works fine on the 3B2 that I am writting this on it does have some problems. I have been trying for some months now to get it run on an INTEL 310 without success. Don't get me wrong, it isn't ELM's fault, the compiler on the INTEL is a disaster. It is also inconsistent. It has some of the system calls for SYSV and some for V7. Makes for some interesting programming. MH is a new one to me but if someone can send me the sources I would be willing to give it a try too. Almost anything is better than vanilla mail. bill gunshannon UUCP: {philabs}\ US SNAIL: Martin Marietta Data Systems {phri } >!trotter.usma.edu!bill USMA, Bldg 600, Room 26 {sunybcs}/ West Point, NY 10996 RADIO: KB3YV PHONE: WORK (914)446-7747 AX.25: KB3YV @ K3RLI PHONE: HOME (914)565-5256
kai@uicsrd.UUCP (09/30/87)
Mush is great. Although it is advertised as a "shell" (and it does have some
shell-like features), I would not recommend using it exclusively as a
replacement for your Bourne or C-shell login shells. It appears to be an
extremely nice substitute for the Berkley Mail (/usr/ucb/Mail) command. It
defaults to line mode commands, like Mail, but has a "curses" mode, like Elm,
as well as a "tools" mode for those lucky enough to have a Sun workstation
with SunTools. We don't, so I cannot comment on tools mode at all.
Command aliasing and history are just two of the added features it provides.
I just got it running a few days ago, and haven't had a chance to test every
little option, but so far I'm impressed. It is much more customizable, and
fixes some obnoxious bugs that appear in Mail.
There is a boolean UNIX options, that when set, passes through any
unrecognized commands to a subshell, so mush works like a regular login
shell. However, no job control, I/O redirection, or piping is allowed with
UNIX commands. This is nice anyway, because it eliminates the escaping to
shells to move, rename, or copy files, or any other little thing you want to
take care of while reading mail.
The documentation is not complete. What is shipped as a man page is over 40
printed pages long, and should be considered a User Guide. A short man page
should be created. Many parts of the user guide are unclear, For example, in
the description of the IF command, it is stated that parenthesis are not
allowed, but some of the examples have them. To satisfy some of folks at my
site, I came up with a short (3 page) summary of line-mode commands,
variables, and command line options, which I will post separately.
Someone complained about the routing capability. While I'm not in favor of
machines changing the route I've selected to follow, it is a settable option,
with the default being off. Dan Heller presents a logical argument for it's
existence (something about wasted UUCP hops), although I've never had that
problems (probably since we are a UUCP Zone domain). Then again, if you WANT
your own mail addresses screwed up, you are certainly allowed to. At least at
the user mail agent level, you aren't screwing things up for other people's
mail that is simply passing through your system, like SOME folks running smail
like to do. (HINT to smail users: contrary to the documentation, you do NOT
need to run pathalias and keep those huge, outdated-before-you-got-them
mod.maps files around).
I would like to hear more detail about the non-RFC822 conforming header
lines. The only one I see that is different than mail is an extra "From:"
line that my sendmail strips out anyway.
One important difference between Mail and mush that is not made clear in the
documentation: On our Sequent B8, Mail reads /usr/lib/Mail.rc followed by
your personal ~/.mailrc (if it exists). Mush reads only ONE startup file. If
searches for ~/.mushrc, ~/.mailrc, and /usr/lib/Mail.rc, in that order, and
only sources the first one it finds.
Without changing the filenames in config.h, you get the undesirable effect of
mush not executing the common system wide commands in /usr/lib/Mail.rc. The
easiest way to avoid this is to create a .mushrc with the first line being
"source /usr/lib/Mail.rc", but folks who just want to "try" mush may think at
first that it is not as nice as Mail, because some things aren't getting set
(only their own .mailrc is executed).
I would prefer that mush do the same thing that Mail does. There are some
options that EVERYONE on our system wants set, but since everyone has some
address aliases, they are forced to copy the entire file to their .mushrc,
wasting a little disk space, and making it hard for the system administrator
(me) to make global changes.
The nicest thing about mush is that I have the source to it, and can make this
addition when I get the time.
Patrick Wolfe
Internet: pwolfe@kai.com
UUCP: ...!{uunet,ihnp4}!uiucuxc!kailand!pwolfe
The opinions expressed here are my own, NOT my employers.allbery@ncoast.UUCP (Brandon Allbery) (10/01/87)
As quoted from <926@trotter.usma.edu> by bill@trotter.usma.edu (Bill Gunshannon): +--------------- | In article <905@bdmrrr.bdm.com>, shprentz@bdmrrr.bdm.com (Joel Shprentz) writes: | > Can anyone comment on how Mush, the mail user's shell just posted to | > comp.sources.unix, compares with Elm or MH? | > | | I can't comment on MUSH yet because I am missing parts 7-12 but I can tell | you that although ELM works fine on the 3B2 that I am writting this on it | does have some problems. I have been trying for some months now to get it | run on an INTEL 310 without success. Don't get me wrong, it isn't ELM's | fault, the compiler on the INTEL is a disaster. It is also inconsistent. | It has some of the system calls for SYSV and some for V7. Makes for some | interesting programming. | | MH is a new one to me but if someone can send me the sources I would be | willing to give it a try too. Almost anything is better than vanilla mail. +--------------- If you thought Mush was big, wait until you see MH! BTW, you'll have even worse problems with MH: it wants either sendmail or MMDF, and is workable but extremely unsatisfying if you have neither. Also, if you have neither you have to kiss BellMail goodbye: MH-MTS (the delivery scheme used if you don't have sendmail or MMDF) wants to write mailboxes in MMDF maildrop format rather thsn Bell-compatible format. As for differences: I can't speak about Mush (didn't even look at it; heck, I've got MH and my own IMS is in the queue for a rewrite), but MH and Elm I have used, and they have radically different philosophies. I suspect from the name that Mush is closer to MH than Elm, but... Elm is a mail user agent contained in a single program plus a few auxiliary programs; the intent is that all mail sending/reading/manipulating is done with the Elm program itself. It attempts to provide a wide range of capa- bilities, but because it is a single program its capabilities are ultimately "fixed" -- difficult to augment. On the plus side, it's relatively small (see below; I'm not talking mailx/ucbmail or BellMail) and has a pleasant, easy-to-use full screen interface. MH, on the other hand, is a collection of utilities for generating and manipulating RFC822-compatible messages. Note that it is not limited to mail; MH 6.5 has support for "bboards", which are a cross between news and mail: submissions are mailed to an alias which saves them into a special mailbox, and standard MH utilities can be used to manipulate these mailboxes even though they are read-only to the majority of readers. The utilities implement _parts_ of a mail user agent; the "utility" connecting them is your favorite shell, supported by Unix files and pipes. This means that if you want to implement a new command, you can write a shell script to do it; there are low-level utilities which can essentially turn _any_ command or program into an MH command. I, personally, swear by it. However, if you're interested in stuff that doesn't require (or at least want) the user to be a shell guru, Elm is the better choice. (MH is definitely the mailer for "power users".) [My own IMS is somewhere in between; it's a single program which can be used as a regular mailer or as building blocks, depending on how it is invoked. The current version isn't as intelligent as it could be and has a few known bugs, but there are still users who swear by it.] -- Brandon S. Allbery, moderator of comp.sources.misc {{harvard,mit-eddie}!necntc,well!hoptoad,sun!mandrill!hal}!ncoast!allbery ARPA: necntc!ncoast!allbery@harvard.harvard.edu Fido: 157/502 MCI: BALLBERY <<ncoast Public Access UNIX: +1 216 781 6201 24hrs. 300/1200/2400 baud>> "`You left off the thunderclap and the lightning flash.', I told him. `Should I try again?' `Never mind.'" --Steven Brust, JHEREG