Usenet 1994 October/usenetsourcesnewsgroupsinfomagicoctober1994disk2.iso/unix/volume18/mush6.4/part01/README

Text File | 1989-03-12 | 15KB | 320 lines

/* @(#)README    2.5    (c) copyright 10/24/87    (Dan Heller) */

Author:
    Dan Heller

Network addresses:
    island![e-mail]        [e-mail]
    [e-mail]

When sending mail, mail to the addresses in the order given.

Contained is the source for "Mail User's Shell" (MUSH), a "Mail User
Agent" (MUA) that is designed to manage electronic mail on most UNIX
systems.  That is, mush is used by users to read mail, sort it, edit
it, delete it, or use it to act as an interface to send mail to others.
A Mail Transport Agent (MTA) is the program which mush communicates with
that actually -delivers- mail.

Redistribution of this code is permitted as long as all copyright notices
remain intact and all other identifying notices remain in the code and
in the binary.  This includes message headers on outgoing mail and the
startup message.  Future releases will extract the release version from
the message headers of mush-originated messages to aid in implementing
features and providing backwards compatibility with previous versions.

With that out of the way...

Mush runs on various flavors of unix.  To build mush, you should identify
which unix you are running:

    Sun (all versions from 2.0 and higher).
    BSD (versions 4.2 and up)
    System-V / Version 7 / System III (Bell Labs)
    Xenix (this might be tricky)

You will need to copy "config.h-dist" to config.h and edit it to reflect
the system dependencies described there.  These consist of "compile-time
definitions and macros."

When it comes to "compile-time definitions", you may use one of two methods:

    #define DEFINITION    /* in the config.h file */
    -DDEFINITION    /* in your makefile */

If the definition is of the form MACRO="string", then use:
    -DMACRO=string
    #define MACRO string

---------------
Which makefile to use:

If you are on a Sun Workstation:

    makefile.sun applies only to suns and creates a binary called "mush."
    If the binary ends in "tool", then the graphics (suntools) mode will be
    used by default on invocation. Otherwise, you must specify -t for
    toolmode on sun workstations.  The SUNTOOL define must is in the
    makefile.sun in order to compile the suntools version.  You don't need
    to be running sunview; old sunwindows (2.0+) may be used.

    If you know that you're not going to use the suntools mode then you
    should use makefile.bsd so that SUNTOOL won't be defined and unnecessary
    files not be compiled so the binary will be made smaller.

If you are on a BSD UNIX machine:

    You should use the makefile.bsd makefile.

If you are using XENIX:

    The files makefile.x286 and makefile.x386 were created especially for
    XENIX machines.  makefile.x286 is for Intel's 80286 processor and the
    makefile.x386 is for the 80386 processor.  The xenix makefiles are
    tuned for SCO's version of xenix.  This does not mean that it won't
    work under other xenix versions -- however, some changes may have to
    be made by hand.  If your xenix release is sco-xenix 2.2 or higher
    then you must define USG. The libraries to use may be -ltinfo instead
    of -lcurses -ltermlib.  This is because the curses package may use
    termio instead of the sgtty data structure.  If you want to use termio
    anyway, even if you're on an older xenix system (that supports termio),
    then you may define USG anyway.

If you are on a system-v Bell labs machine:

    makefile.sys.v is for unix machines that are not running any flavor of
    BSD and probably running a system-v flavor of unix -- this defines USG
    so that termio will be used.

When you decide on an appropriate makefile, _copy_ it to a new file called
Makefile.
---------------

Your Mail Transport Agent:
Sendmail:
    Mush was originally designed to use sendmail as the Mail Transport Agent.
    However, other MTA's will work.  The MTA you use should be defined in
    config.h under the MAIL_DELIVERY macro define. By default,
        /usr/lib/sendmail -i
    is used -- the option, -i, tells sendmail not to accept "." on a line
    by itself as an end-of-file marker.  This has been bosleted by "-oi",
    but "-i" still works and is backwards compatible with older sendmails.

Delivermail:
    Some mailers such as delivermail and MMDF use special strings to separate
    messages stored in a folder.  Older delivermail versions would use "^C".
    Whatever your system uses, if it is NOT "From " (just the first 5 chars
    on a line matching "From "), then this string should be defined in
    config.h with the MSG_SEPARATOR macro.

MMDF:
    NOTE: MMDF sites can define MMDF and not worry about MSG_SEPARATOR.  See
    config.h-dist if you run MMDF.
    Since MMDF can deliver users' mail in their home directories, there is
    a new define to specify this option: -DHOMEMAIL
    Since MMDF uses its own libraries to do file locking, you should add the
    appropriate library to the LIBS list in your makefile.

All others:
    Chances are, your MTA uses the "From " format to separate messges in
    a folder.  This includes, /bin/mail, rmail, smail, execmail, and so on.
    Unless you *know* otherwise, assume this to be the case with your MTA.

    If no MSG_SEPARATOR is specified, what mush looks for is a pattern of
    From <string> <date format>
    The "string" is usually the return address of the sender and the date
    format is supposed to be in ctime(3) format.  Even still, some MTAs
    don't conform completely to this standard and vary slightly in
    implementation.  The function load_folder() (which reads in messages)
    contains a scanf which looks for this format to verify that this is
    indeed a new message being scanned.  If you install mush and find that
    you are entering a shell, but mush indicates there are no messages in
    the folder, it could be that you have a weird "From " line format and
    the scanf() call needs to be either modified or removed.

#defines specifically for your MTA:

OLD_MAILER:
    Some MTA's, especially older ones like /bin/mail or execmail (xenix), do
    not conform to RFC822 and provide the required headers: From: and Date:.
    To remedy, either #define OLD_MAILER in config.h or add the -D option
    OLD_MAILER in the appropriate makefile: -DOLD_MAILER.  What this does is
    make sure that there is a From: and Date: header in outgoing messages and
    in folders (such as "set record").  Sendmail should not define this.

UUCP:
    If your machine talks to other computers via uucp _and_ you have the
    macro OLD_MAILER defined,  then you may want to define UUCP.  This will
    change the From: line to have your return address look like "host!user"
    rather than "user@host" (which is the default).  If you don't have
    OLD_MAILER defined, this define does nothing.

NO_COMMAS:
    If your mailer does *NOT* like commas between addresses (pre-3.0 smail,
    xenix and sys-v machines), then you should define NO_COMMAS.  Otherwise,
    you will get mailer-daemon [type] messages back when trying to send mail
    to multiple users.  Sendmail should not define this.

VERBOSE_ARG:
    If your mailer does NOT have a verbose option, then you should not have
    VERBOSE_ARG defined.  Otherwise, define it to be whatever the verbose
    argument is for your mailer.  The default is -v.

METOO:
    Sendmail uses the -m argument to say, "metoo" -- when sending to mailing
    lists, normally sendmail will send mail to mailing lists, but if you're
    in that list, you are excluded from getting your own mail.  However, if
    you have the variable metoo set with your variables, then the METOO
    argument is passed to sendmail to say, "I know I'm on this mailing list,
    but send me a copy of my message even tho I sent it."  For sendmail, this
    is -m.  If your mailer uses something else, then define METOO_ARG in the
    config.h file.  If you don't have it (sys-v), then this should not be
    defined.

---------------
Signals:
SIGRET:
    When signals occur in unix, the program can identify a function to be
    called whenever a specific signal interrupts the process.  That function
    returns one of two types in unix: int and void.  Because the return value
    of this function is always ignored, many unix systems are converting
    their definition of this function from int to void.  Mush has a define:
    SIGRET which defines what the function should return.

    By default, SIGRET is defined to be "int".

    SunOS4.0 and some system-v machines and some xenix machines should
    define SIGRET to be void.  If you don't know, leave it alone.  If
    you guess wrong, you will get compiler "warnings" on lines that read:
    on_intr();
    off_intr();

---------------

VPRINTF:
    This should be defined if your system has the vprintf functions. You
    *have* these functions if you are running:
    o system V
    o xenix
    o Sun release 3.0 or higher.
    If you are still not sure, try the following command from your shell:

    % ar t /lib/libc.a | grep vprintf

    If you have it, you'll probably get something like
    vprintf.o
    vsprintf.o
    as output.  If you don't have it, you won't have any output.  If your
    main C-libraries are not in /lib/libc.a, then find where they are and
    try the same command using that file.  BSD machines do not have vprintf().

---------------
The sprintf() function:
    If you *know* your system's sprintf returns a char *, you can remove the
    #define sprintf Sprintf
    in strings.h.  Careful, not all BSD4.3 machines are alike!  If you don't
    know for sure, don't change this define.

---------------
Regular expression defines:
    If you have REGCMP, this should be defined so that you will use the
    routines regcmp() and regex() as the regular expression composer/parser.
    This is true for xenix and System-V Unix.
    If you don't have REGCMP defined, then the routines re_comp() and re_exec()
    are used (this is the default for mush).

    Note that some systems do not have either set of routines in the default
    libraries.  You must find the library to use and add it to the list of
    libraries to use.  If this is the case, your link will fail with the
    errors that regex and re_comp are undefined functions.  Read your man
    page for regex(3) to find where to locate those libraries.

---------------
The select() function call:
    Mush uses select() to implement macros, mappings and bindings.  If your
    system is a BSD system, then this is defined for you.  However, with the
    advent of hybrid bsd/sys-v systems, you may not be able to set BSD, but
    you know you still have select() --for such systems, define SELECT in
    your makefile or in config.h.
    Newer xenix machines have this as so some system-v machines.  If you don't
    know, mush will use another function although not as optimum as select().

---------------
The default Mailrc startup file:
    A default mailrc should be installed for new users.  UCB mail's default
    Mailrc works but no mailrc works also. The location of the default
    file should be defined in config.h.  To have no default mailrc, set the
    default to /dev/null.
    For sun systems, the default .mailrc (/usr/lib/Mailrc) does not work
    very well because sun's Mail is not standard /usr/ucb/Mail.
    For this reason, sun has not changed the default mailrc file and still
    resides in /usr/lib/Mail.rc (note this has the "." whereas the other file
    does not).  The default config.h-dist reflects this.

    There is a supplied Mushrc file with mush, but this is only intended to
    be used as an example of how to make mush look like ucbMail.  This is a
    _reduction_ in functionality and its usage is not encouraged.

    There is a Gnurc file which can aid in making mush's curses mode appear
    to interact similar to gnu-emacs.

---------------
Help files:
    The help files should be placed somewhere which is readable and accessible
    by all. Failing to do so removes virtually the entire help facility's
    ability to help anyone.  There is a help file (cmd_help) for command help
    (e.g. "command -?"), and the tool_help is for the graphics mode (Sun
    workstations only).  You should define where you want these files in
    config.h so at runtime, they can be accessed without error.

---------------

You should now be able to run make.

---------------
Maintenance:

If you want to use dbx or any other debugger, or to use your default tty
driver, -e should be used as command line argument when you run the program.
What this flag does is prevents your echo from being turned off and leaving
cbreak off, thus, keeping your tty in a sane state.  This prevents the use
of mappings and macros (map and map!).  However, curses mode will automatic-
ally disable that mode.  The -e flag is highly discouraged.

If you have memory allocation checking and validation (sun 3.0+ ?) then
define M_DEBUG in the makefile (main.c) and add the library
/usr/lib/debug/malloc.o to the library list. Do this only if you are
find bugs in the program and suspect memory allocation errors. main.c
has the code which sets the debugging level according to the value of
an environment variable.  Because malloc-debugging is so cpu intensive,
the sunwindows program will get a SIGXCPU (cpu time limit exceeded)
because of the large amount of opening and closing large pixrects and
devices.  For this reason, SIGXPCPU is is caught in main.c.

The "warning" variable may be set (at runtime in your .mushrc or as
a command: "set warning") to aid in finding runtime errors that aren't
fatal.

If you ever get "Message N has bad date: <date string>" then note
the FORMAT of that date and edit dates.c.  There are a number of
"sscanf"s which you can see match known date formats.  Use them as
examples and insert the new date format you have.

If you ever add new variables, be sure to add them in viewopts.c and the
man page.

If Mush ever coredumps and you are suspicious about whether or not
your folder (or spool directory) was removed.  Or, if you were editing
a letter, you should check for the files .mushXXXXXX and .edXXXXXXX.
Mush won't die without telling you that it's dying and it will ask if you
want to save the .mushXXXXX file and if you actually want it to dump core.
Note that if you run mush from .suntools and there is a core dump, it
probably wants to do some IO with the console and may hang (not exit)
because it doesn't know it can't talk to you.

Last attempted, mush passed lint with a small number of errors indicating
that fflush, fclose and other similar functions returned values which
were always ignored.  Sorry.  I did not attempt lint on the suntools mode.
Curses doesn't lint very well, but even when you lint mush with CURSES
defined, it only complains about the unused curses globals in curses.h.