E-mail Made Easy Unix automates mail delivery
From "Migration",  Access to Wang, October 1994
[ Prior Article ]     [ Return to the Catalog of articles ]     [ Next Article ]

One of the strengths of Unix lies in its abilities to communicate. From batch file transfer using UUCP (Unix-to-Unix Copy) through sophisticated network tools like NFS (Network File System, a way to make remote systems appear like local disks), Unix provides many ways to exchange information. The presence of strong standards in these systems means that it is usually irrelevant whether the information originated on given vendor's equipment, and there is a good selection of quality products to enhance these systems.

Unix mail systems are a part of this, riding on the strong transport capabilities of the operating system. Mail may be exchanged within a single organization or distributed to the world (literally), as needed.

Here is a brief description of Unix mail and some ways you might want to use it in your organization.

Beginning Unix mail

In most Unix systems, your startup profile checks for unread mail during the login process and issues a terse alert ("You have mail.") if you have unread mail. Similar messages may also appear as other mail is received during a session. If your system's users are directed into a menu system rather than the command prompt - as most former Wang users would prefer - these messages will appear briefly before the menu programs are invoked. To send or read mail, access to a mail application must be provided, but this access could also be set up as a menu item.

Most Unix systems have several ways to use mail. One of the simplest is mailx, also known as Mail or mail, which works from a command prompt. Here is a sample sequence showing how to create a message using mailx:

$ mailx dsb Subject: Test message This is a line of the message. This is the last line of the message. . EOT

The first line is the command to invoke the mail system (mailx in this case), followed by the user ID of the recipient. The mail program prompted for the subject line, then accepted message text lines. To close the message, a period was entered in column one and the program returned the EOT (end of transmission). Some simpler mail systems do not prompt for subject, but a subject can be added to the text of the message by starting the first line with word "Subject" followed by a colon (e.g. "Subject: Test message"). Subject lines are recommended for all messages so the receiver can see what the message contains without opening it first.

To check for mail you have received, enter the mail command alone ("mailx"). If you have no unread message, most systems will return a message indicating this ("No mail for dsb"); otherwise, either a summary of mail or the first message will be displayed, depending on the mail system used. The mailx program shows a condensed listing of messages with the status (unread, read, new), sender ID, date and time sent, line and character counts, and the subject; short commands may be entered at this point to read a message, delete a message, save a message to a folder, reply to a message, or several other functions. (mailx also offers a large number of "tilde" commands - commands that begin with a tilde (~) - for advanced purpose. Consult the manual pages for your system for a description of these options.)

Program generation of mail messages

The same mail sending process described above may be automated by using a file as input to the mail program. For example, suppose you created a file named message.txt containing the following text:

Subject: Test message This is a line of the message. This is the last line of the message. .

This file could be mailed to user dsb with the following command:

$ mail dsb < message.txt

This uses Standard Input to supply the text of the message to the mail program. A similar approach could be used in scripts or programs to distribute messages, reports, or reminders. (Notice I have used the mail program rather than mailx in this example. On our system, mailx is not able to accept a subject line from text, so I use mail instead.)

A more advanced example is shown in the dirlist.sh shell script shown in Figure 1. This script sends a copy of a directory listing - directory /usr/tmp in this case - to three users. Some features of this script include:

• Shell variables: The user IDs of the recipients are contained in the shell variable MAILRECIP, allowing easier modification to the script. The value of these variables is substituted on line 14 by adding a dollar sign to the variable name.

• Command substitution: Line 8 contains a command that invokes the date function, placing the current date and time into the text file. Note the accent graves (`), which look like backward apostrophes; these tell the system to perform a command and return the results to the echo process. Another command substituion is used to gather the directory information on line 12, using the ls command.

• Multi-line echo: Beginning with the double quotes on line 6, all of the information echoed by the system - including the results of the command substitution statements - is captured in a file until the next set of quotes on line 12. This is captured in a file using Standard Output.

• Temporary file name, process ID: A common way to create unique names for temporary files on Unix systems is to use the process ID, a unique number assigned to every Unix process. In shell programming, two dollar signs can be used to specify the value of a process ID. Thus, the name of the file created on line 12 might be "message.14432". (It is important to be careful to find unique names for output files, since Unix normally overwrites existing files with the same name without warning.) The temporary file is removed in line 15.

Scripts such as this can be used to monitor system process, remind you of tasks to be perfomed, and log events. The use of script-generated mail can help replace some of the functionality of the Wang Operator Console, informing technical users about job and system problems.

Advanced mail

Other mail applications are also available. Many Unix vendors include Elm, a menu-driven mail application that is much easier to use than command-prompt mailers; another good mailer is Pine. Elm is included with many vendor's software, while Pine can be obtained from Internet file providers or other sources. Both Elm and Pine are copyrighted by their developers but available with no licensing requirements or cost. Either of these programs provide easier access to mail. Note that all Unix mail applications share a common file and distribution system. Individuals may choose mailx, Elm, Pine, or almost any other Unix mail application and still be able to exchange information with others not using that application.

Those used to the polished appearance of applications like Wang Office will view Unix mail systems as crude, text-only tools. In the spirit of most Unix applications, these mailers are designed to work with a wide variety of terminal types and make no assumptions about the presence of function keys or other keyboard features. Most use brief commands instead of function keys, and many of these commands are similar to other Unix utilities so they are easy to learn.

If your system is connected to an Internet provider, the Pine mailer can also be used to read postings on the Usenet news groups. These groups, which function like electronic bulletin boards, often provide critical information for systems support and enhancement. There are presently, over 5,000 news groups, including many aimed at specific hardware and software needs. Message activity is often very high; I've noted about 400 new messages a week on a HP-related news group. Most messages are questions and responses to questions from end users, but many vendors participate in the discussion. In many ways, these news groups replace the function of vendor user groups but allow you to stay up with many vendors rather than just one.

Unix mail can be thought of as two parts: the mail application that presents messages to the user, and the underlying transport that moves messages between users and systems. All distributions of Unix contain the transport portion of mail, and interchange between Unix systems is relatively easy to set up. Besides mail, this distribution mechanism is also used for file transfer, system time synchronization, and many other purposes. Some of those uses will be covered in this space in the future.

Figure 1: Sample Script - Generates Report and Mails It

1 #!/bin/sh 2 # dirlist.sh - creates a directory listing & mails it to selected users 3 4 MAILRECIP="dsb abc xyz" 5 cd /usr/tmp 6 echo "Subject: Directory listing 7 8 `date` 9 10 Contents of the /usr/tmp directory: 11 12 `ls -la`" > message.$$ 13 14 mail $MAILRECIP < message.$$ 15 rm message.$$ 16 exit 0