argv@garp.mit.edu (Dan Heller) (09/23/87)
I received the following mail and thought the net deserved an appropriate
response...
------------------
>From sun!spam.istc.sri.com!rutgers!umix!itivax!mnetor!dalcs!silvert Fri Sep 18 13:01:16 1987
Return-Path: <sun!spam.istc.sri.com!rutgers!umix!itivax!mnetor!dalcs!silvert>
Date: 18 Sep 87 15:54 -0300
From: Bill Silvert <sun!spam.istc.sri.com!rutgers!umix!itivax!mnetor!dalcs!silvert>
To: <argv@spam.istc.sri.com>
Subject: Mush
Status: OR
This is a big package, and before I start installing it for test purposes
it would be nice to know a bit more about it. At present we are pretty
happy with ELM, although it has some bugs, and it would be very nice to
have a sales pitch (for freeware?) telling it what MUSH does that nobody
else has accomplished.
It sounds like MUSH is optimized for Sun's, but since I have a small SYSV
system, I would like some idea of the cost/benefit ratio. We use mail a
lot, so I don't want to pass on a good bet, but it isn't clear what we are
getting into.
Sorry if I seem to be looking a gift horse in the mouth, but you've obviously
felt it was worth the trouble to develop your own very elaborate mailer (as
has Dave Taylor), and I want to know if you were targetting the same needs
as we have. Your reply will be appreciated, but you may prefer to post a
general exposition of how MUSH compares with what else is out there, as Dave
has done (although I don't recall whether that was in a posting or in one
of the distribution DOC files).
----------------------------------------------------------
I'm not familiar enough with ELM or any other mailer to warrant my making
a statement to the effect of "... use Mush instead of mailer X because it
does this-and-that and that mailer doesn't..." I do know about the mailers
you get with vanilla unix boxes and that's what I compare mush with.
ucb-mail on BSD systems and mailx on xenix (sys-v, too?) is too limiting
for practical use. I wanted to build a package that is convenienct to
use in line mode -- like a shell -- but also has the ability to work in
curses mode to take advantage of terminal attributes. I want the ability
to toggle back and forth between them with limited headache. The suntools
part was there because at the time, there was no mailtool (or sunview).
Mush is similar to ucb-mail in the way it stores mail so you can run mush
and ucb-mail interchangeably. People who are familiar with ucb-mail can
run mush without having to relearn a lot. They can run the same commands,
even use the same .mailrc file (except for newer sun releases which have
become quite incompatible with the rest of the ucb-mail world). When you
pick up something new, it's very nice to already be somewhat familiar with
it; it's much less intimidating. But ucb-mail doesn't take advantage of
screen optimization like elm or a screen editor.
I tried to build all the interfaces with as much user-configurability as
possible; in the shell, you can command line aliases and the history
mechanism like csh; the suntools interface allows function key settings
in addition to settable options; the curses interface is also configureable.
You can "bind" key sequences (like function keys or regular ascii sequences)
to commands to allow more a user definable environment. It can toggle
between curses mode and the tty (shell) mode just as you do using "vi".
It optimizing redrawing the screen only when necessary, so if you're on a
slow terminal, it knows how big to make the window, whether it should redraw,
and so on. Screen movement and some commands are very reminiscent of vi.
You can do pattern searches easily, access help, everything that you can do
from the other interfaces. If you don't like vi, set up the key bindings to
be similar to emacs or whatever. I don't use emacs, so I don't know how
easy this really can be (it may not be).
User friendliness and flexibility are often enemies -- to make something
user friendly sometimes means "don't allow too many options" because you
end up confusing the user, or making him indecisive and frustrated. Because
of this, much functionality in the suntools interface is not available
(the 'pick' command) -- the curses interface allows all the commands, but
may not allow all the options. However, the curses interface is easier to
work around since all you have to do is type ':' and the command and it's
done. Clearly, the most robust and useful interface is the line-mode one.
One thing to be careful about the shell mode is that metacharacters (such
as * - . $ { }) have different meanings than csh. These characters represent
"message lists" which are considered as "input" to all mush commands. There is
no filename expansion because you're not dealing with files, you're dealing
with mail messages. Interacting with the filesystem is available in many
ways the c-shell accesses it -- you can still say, "save ~user/foo"
You just can't do things like "~r *.c" to read in all the .c files in the
current directory. When you "redirect" input or output to/from a mush
command, what you're redirecting is a message list -- a list of messages
that the last command affected or a list of messages the next command is
supposed to affect.
1-10 | pick -f frank
This means take messages 1 thru 10 and use them as the input to "pick".
i.e. Pick from messages 1-10 the ones that are from "frank". The output
will be those messages from frank; if messages 3,5 and 7 are from frank,
then that will be the output. If the output is not redirected, you would
see the headers for those messages ... if out is redirected to "delete",
for example ("1-10 | pick -f frank | delete"), then 3,5 and 7 will be deleted.
Everyone seems to have their favorite aspect of mush that appeals to him/her
the most. Some who use xenix (sys-v) say the really like the fact that it
emulates the BSD-style tty driver (which allows backspace-space-backspace,
^W and ^U). Because you can run unix commands right from Mush ("set unix"),
you can interactively shell commands without doing _slow_ popen() calls
that redundantly source .cshrc's or .profiles (there are also internal setenv
and unsetenv routines). And the most popular among the ucb-mail users
seems to be the fact that when new mail comes in, it's right there in your
folder (appended) -- you don't have to update or quit/restart, or anything.
You get a message telling you of the new mail, from whom, and the new
message numbers. Mush is aware of job control so you can ^Z at anytime and
be returned to the right place in the right tty modes when you return.
To faciliate the use of job control, there is a 'stop' command which will
stop the shell for you -- if you cmd (command line alias) 'quit' to
'update;stop' when you type "quit" (or, q), your mail is updated and
mush stopped. When you get new mail, you can "fg" and there's the new mail.
You don't need to reinitialize the package and restart the whole shell
because you never exited it to begin with.
Misc options are provided for those who like to automatically enter an
editor every time they send mail ("set autoedit"). If you want to
automatically include a copy of the letter you're replying to whenever
you reply to a message, set autoedit. If you want to filter your mail
so that all mail from a newsgroup is saved to a folder, all mail addressed
to a particular alias is queued somewhere else, etc... scripts can be written
to do this easily (scripts are a little like shell scripts).
The suntools portion of Mush is a separate interface which the rest of the
code is not dependent on. Mush is *not* designed to run "best" on suns --
The code doesn't care whether you're running the tool mode or curses or
text mode. The advantages that Mush's tool mode has over sun's Mailtool:
you can run it on old sunwindows (2.0 and up); you can use the editor of
choice to compose messages; the icons always tell you how many messages
you have; there's an interface for setting your function keys to commands;
the list goes on. And it doesn't remove your mail if you're running biff
at the same time :-)
Oh, and I should also mention that you can set "indent_str" to a string
to use (like "> ") so all your "included" mail is indented with that string.
There is quite a bit more to mush than what I've described here; the man page
is long, but "packed"; that is, it is to be used as a _reference_ manual, not
a tutorial. There is extensive help provided for mush in two helpfiles
(one is for tool mode help only). Each command can be preceded by a "?"
to mean, "give me help on this command." Or the -? option can be used
virtually anywhere; in more places than you might expect. Sometimes, my
verbiage might be too technical or wordy for the true novice, but if you
can use ucb-mail, there's no reason you can't figure out mush.
After all I said above, I still feel like I didn't answer the most important
question asked in the beginning: "... and I want to know if you were targetting
the same needs as we have." Well, you didn't state what your needs were
explicitly, but my general impression is that you want something better
than the default mailer provided with your computer, something user friendly,
functional, small, runs on your unix box -- you know -- the world. All I
can say is, give it a try.
My biggest problem here is that I my access to the net is not easy or frequent.
My account at MIT is very helpful and appreciated, but I live in Northern
California -- a call to Boston to read the news isn't going to be made often.
When there are updates, I'll post them and if there are severe bugs (that
cause coredumps or equally nerveracking mental conditions), I'll get to it
as fast as humanly possibly. I do a have a real job on the side, you know. :-}