4.2_BSD_User_Contributed_Software 4.2 BSD User Contributed Software

4.2_BSD_User_Contributed_Software manual pdf -FilePursuit

4.2_BSD_User_Contributed_Software 4.2_BSD_User_Contributed_Software

User Manual: 4.2_BSD_User_Contributed_Software

Open the PDF directly: View PDF PDF.
Page Count: 80

Download4.2_BSD_User_Contributed_Software 4.2 BSD User Contributed Software
Open PDF In BrowserView PDF
User Contributed Software
Supplemental Manual
August. 1983

Computer Systems Research Group
Department of Electrical Engineering and Computer Science
University of California
Berkeley, California 94720

User Contributed Software

The following is a list of acknowledgements to the people and organizations
who contributed software for 4.2BSD.

AEL
Authors:

John D. Bruner
Lawrence Livermore Laboratory
P.O. Box 808. 1-276
Livermore. CA 94550
(415) 422-0758
Prof. Anthony P. Reeves
Cornell University. Phillips Hall
Itllaca. NY 14853
(607) 256-4296

This implementation of APL is a descendent of a program originally written
by Ken Thompson at Bell Labs sometime before UNIXt version 6. It went to Yale
for a while and then came to Purdue (Electrical Engineering) via a Chicago distribution in 1976. It was extensively modified at Purdue by Anthony P. Reeves.
Jim Besemer~ and John Bruner. The editor "apled" which APL uses to edit functions was developed from the V6 "ed" editor by Craig Strickland.
Improvements which were added at Purdue/EE include quad 1/0 functions,
a state indicator of sorts. statement labels, and a number of primitive functions.
The current version runs on both large V7 PDP-11's (those which are capable of
running 'separated <'lID -programs) and VAXes. (Workspaces' are not directly
interchangeable but can be converted).

Bib
Authors:

Timothy A. Budd
Gary M. Levin

Address:

Department of Computer Science
University of Arizona
Tucson. Arizona 85721
(602) 621-6613

Bib is a program for collecting and formatting reference lists in documents.
It is a preprocessor to the nroff/trot! typesetting systems,. much. like the tbl
[.tbl.] and eqn [.eqn.] systems. Bib takes two inputs: a document to be formatted and a library of references. Imprecise citations in the source document are
replaced by more conventional citation strings. the appropriate references are

August 11. 1983

-2selected from the reference tne. and commands are lenerated to format both
citaUon and the referenced item in the bibliography.
COl1rjer

Author:

Eric C. Cooper

Address:

Computer Science Division. EECS
University of California
Berkeley, CA 94720

Net address:

cooperOberkeley (ARPA)
(tnJCP)

ucb~cooper

This is the Courier remote procedure call protocol for Berkeley UNIX (version 4.2). Courier is both a protocol and a specification language. The protocol
specifies how remote procedures are invoked and how parameters and results of
various data types are transmitted. The specification language. somewhat reminiscent of Mesa. provides a simple way of defining the remote interfaces of distributed programs.

Author:

Helge Skrivervik
berlensveien B, N - Oslo 9. Norway

Net address:

belge@berkeley
helgeOnta-vax (norway)

Cpm lets UNIX users read and write standard cp/m B"tloppy disks and provides a cp/m like user interface for manipulating cp/m files.
Dsh (distrib11ted shell)
Author:

Dave Presotto

Address:

University of California
Computer Science Division. EECS
Berkeley, CA 94720.

Net address:

presotto@berkeley (ARPA)
UCbV"dx!presotto (UUCP)

Dsb works in two phases: bidding and execution. The bidding is performed
by starting a dbid program on aU the requested machines (using rsh). The
dbid's send back bids using the ipc. The dsh command then picks some subset
of the bidding machines and runs the requested command on them. once again
using rsh.

August 11. 1963

-3 ...

HyperchanneJ driver
Author:

Steve Glaser

Address:

Tektronix M/S 61-215
P.O. Box 1000
Wilsonville. OR 97070
(503) 685-2562

Net Address:

steveg. tektroni.x@rand-relay (ARPA)
teldabsl steveg

This is release 2.1 of the hyperchaIUlel driver and related programs.
It is being actively used on one machine at Tek (soon to bring up a few more
machines). It has been used successfully to communicate with a CDC Cyber.
vax/unix under unet. and PDP-l1's under unix/unet. It is working on a 11/780.
It has not been tested on a 11/750 or 11/730 although there should not be any
di(fj.culties.

ICON
Aut.hor:

Ralph E. Griswold
Department of Computer Science
The University of Arizona
Tucson. AZ B5721

Net address:

icon-project.arizona@rand-relay

Icon is a high-level. general-purpose programming language that is wellsuited for nonnumerical applications. Icon supports several data types. including variable-length strings, lists with flexible access methods. and tables with
associative lookUp. Storage management is automatic. Icon has a goal-directed
evaluation mechanism that allows concise solutions of many programming tasks
to be formulated easily. Its string scanning facility is comparable to pattern
matching in SNOBOL4, but Icon allows all language operations to be used in the
analysis and synthesis of strings. With its high-level facilities and emphasis on
string and list processing. Icon tills a gap in the UNIX language hierarchy.
The design and implementation of Icon was supported. in part. by the
National Science Foundation under grants MCS75-01397. MCS79-03B90. and
MCSB 1-0 1916.
learn scripts for the vi editor
Author:

Pavel Curtis

Net address:

Idecvax. vax135. allegra.harpo•... J!cornell!pavel
Pavel. Cornell@Udel-Relay

August 11. 1983

-4-

I

1lH maiJ

Authors:

Bruce Borden
Stockton Gaines
Norman Shapiro

Help from:

Phyllis Kantar
Robert Anderson
David Crocker

~t ..m

The user command interface to Wi is the UNIX "shell" (the standard UNIX
command interpret.er). Each separable component of message handling. such
as message composition or message display, is a separate command. Each program is driven from and updates a private user environment. which is stored as
a me between program invocations. 'Ibis private environment also contains
information to "custom tailor" MH to the individual's tastes. MH stores each
message as a separate me under UNIX and it utilizes the tree-structured UNIX file
system to organize groups of files within separate directories or "folders." All of
the UNIX facilities for dealing with tiles and direct.ories, such as renaming. copying. deleting. cat.aloging. off-line print.ing. etc.. are applicable to messages and
directories of messages (folders). Thus, important. capabilities needed in a message system are "available in Wi without. the need (often seen in other message
systems) for code that duplicates t.he facilities of the supporting operating system. It also· allows users familiar with the shell t.o use MH wit.h minimal etTort.
Nntesfiles

Aut.hors:

Ray Essick
Department of Computer Science
222 Digital Comput.er Laboratory
Univetsity of IDinois at Urbana-Champaign
13Q4. West Springfield Ave.
Urbana. n. 61BOl
uiucdcslessick
(UUCP)
essick.uiucOrand-relay (ARPA)
Rob Kolstad

Parsec Scientific Computer Corporation
Richardson. TX
parsec!kolstad
(UUCP)
Not.estlles support comput.er managed discussion forums. Discussions can
have many ditferent purposes and scopes: the notestlle system has been
designed to be flexible enougb to handle differing requirements.
Each notestlle discusses a single topic. The depth of discussion within a
notesftle is ideally held constant~. While some users may require a general discussion of personal 'Workstations, a ditferent group may desire detailed discussions about the 1/0 bus structure of the WlCAT 68000 (a particular workst.ation).
These discussions might well be separated into t.wo di1ferent notestiles.

August 11, 1983

-5Each notesflle cont.ains a list of logically independent not.es (called base
notes). A note is a block of text with a comment or question intended to be seen
by members of the notesftle community. TIle note display shows the text. its
creation time, its title, the notesftle's title. the author's name (some notesftles
allow anonymous notes). the number of "responses". and optionally a "director
message". Each base note can have a number of "responses": replies, retorts.
further comments, criticism. or related questions concerning the base note.
Thus.' a notesftle contains an ordered list of ordered lists. This arrangement has
historically been more convenient than other proposals {e.g., trees were studied
on the PLATO (trademark of CDC) system).
The concept of a notesftle was originally implemented at the University of
minois, Urbana-Champaign. on the PLATO system (trademark of Control Data
Corporation). The UNIX notestile system includes these ideas with adaptations
and enhancements made possible by the UNIX environment.
The UNIX notestue system provides users with the abilities to read notes and
responses. write notes and responses, forward note text to other users (via m~il)
or other notesflles, save note text in their own tiles, and sequence through a set
of notestiles seeing just new text. Each notestlle has a set of "directors" who
manage the notesflle: they delete old notes. compress the file when needed,
,rant and restrict access to the notesftle, and set ditferent notesfile parameters
(e.g., title, "director message", policy note, whether notes' authors can be
anonymous). Some notesfiles contain correspondence from other computers.
Like 'the UNIX "USENE!". notes and responses are exchanged (often over phone
lines) with remote machines. The notesfile system provides automatic exchange
and updating of notes in an arbitrarily connected network.

Res Revision Control

System

Author:

'Walter F. Tichy

Address:

Department of Computer Sciences
Purdue University
West Lafayette, IN 47907

Net address:

wft@purdue(ARPA)

The Revision Control- System (RCS) manages multiple revisions of text files.
RCS automates the storing, retrieval, logging, identification, and merging of revisions. RCS is useful for text that is revised frequently, for example programs,
documentation. graphics, papers, form letters, etc.

Sccstorcs
Author:

Kenneth L. Greer
2065 Alma St.
Palo Alto, CA 94301

Net. address:

kg.HP-Labs@Rand-Relay

Sccstorcs builds anRCS Revision Control System file from an secs Source
Code Control Syst.em tile. The delta.s and comments for ea.ch delt.a are preserved
and installed into the new RCS me in order. Also preserved are the user access
list and descriptive text. if any, from the sces flle.

August. 11. 1983

-8-

BPMS - Software project Management System
Author:

Pet.er J. Nicklin

Address:

University of California
Computer Syst.ems Research Group
Comput.er Science Division, EECS
Berkeley, California 94720.

Net. address:

nicklin@berkeley (ARPA)
ucbvax!nicklin (UUCP)

The Software Project. Management. Syst.em (SPMS) is a syst.em for t.he
management of medium- to large-scale soft.ware syst.ems. SPMS provides. within
the UNIX environment, a number of commands which can greatly simplify many
tasks associated wit.h program development. and maint.enance~ SPMS does not
at.tempt to duplicate exist.ing UNIX program development tools such as m.ake or
but. instead provides a way of coordinating these tools.
. SPMS can be titted to existing software systems. It retains the full capabilities of the UNIX environment with unrestricted access t.o UNIX tools. As a result,
software packages developed using SPMS do not depend on the system for their
survival and can be ported to versions of UNIX that do not support. SPMS.
The design and implement.ation of SPMS was support.ed. in part, by DARPA
under grant (DARPA) N00039-C-0235.

sees.

IISENET ("readnews") Version B Software

Aut.hor:

Matt Glickman

Address:

Computer Systems Research Group,
Computer Science Division, EECS
University of California,
Berkeley, California 94720

Net address:

glickman@berkeley(ARPA)
ucbvax!glickman(UUCP)

The USENET is a network of UNIX machines t.hat exchange news articles on a
frightening variety of topics known as newsgroups. To join the network, the user
must. find a machine already on the network willing to forward articles. News can
be exchanged over UUCP. Arpanet, ethernet, or practically any network t.hat
allows file transfer and/or mail. The two main programs are rea.dnews. the article reading program and inews, the article insertion program.

August 11, 1983

-7-

Uiscel1anpOl1S tools

Aut.hor:

John Kunze

Address:

P.O. Box 4086
Berkeley, CA 94704

Net address:

jak%monet@berkeley (~A)

The programs here are intended to be general programmer's tools.
jot. - print sequential or random data
lam - laminate files
rs - reshape a data array
Enhancement.s are planned for the rs command.

August 11. 1983

An Overview of the Icon Programming Language

•

Ralph E. Griswold

Department of Computer Science
The University of Arizona, Tucson, AZ 85721
February 27, 1983

1. Introduction
Icon is a high-level programming language with extensive facilities for processing strings and lists. leon has several novel features, including expressions
that may produce sequences of results, goal-directed evaluation that automatically searches for a successful result, and string scanning that allows operations
on strings to be formulated at a high conceptual level.
Icon resembles SNOBOlA [1] in its emphasis on high-level string processing
and a design philosophy that allows ease of programming and short, concise programs. Like SNOBOlA, storage allocation and garbage collection are automatic in
Icon, and there are few restrictions on the sizes of objects. Strings, lists, and
other structures are created during program execution and their size does not
need to be known when a program is written. Values are converted to expected
types automatically; for example, numeral strings read in as input can be used in
numerical computations without explicit conversion. Whereas SNOBOlA has a
pattern-matching facility that is separate from the rest of the language. string
scanning is integrated with the rest of the language facilities in Icon. Unlike SNOBOlA, Icon has an expression-based synt~x with reserved words; in appearance,
Icon programs resemble those of several other conventional programming
languages.
Examples of the kinds of problems for which Icon is well suited are:
•
text analysis, editing. and reformatting
•
document preparation
•
symbolic mathematics
•
text generation
•
program parsing and translation
•
data laundry
•
graph manipUlation
Icon is implemented in C [2] and runs under UNIXt on the PDP-ll, VAX-ll,
and Onyx C8002 computers. Implementations for other computers and operating
systems are presently underway. An earlier version of Icon [3] is available on
several large-scale computers, including the CRAY-l, DEC-10, IBM 360/370, PRIME
450/550/650, DG MV8000, and CDC Cyber /6000.
,;This work was supported by the National Science Foundation under Grant MCS81-01916.
UNIX is a trademark of Bell Laboratories.

-2-

A brief description of some of the representative features of Icon is given in
the following sections. This description ,is not rigorous and does not include many
features of leon. See [4] for a complete description.

2. Strings
Strings of characters may be arbitrarily long. limited only by the architecture of the computer on which Icon is implemented. A string may be specified
literally by enclosing it in double quotation marks. as in
greeting := "Hello world'
which assigns an ii-character string to greeting. and

address := '"'
which assigns the zero-length empty string to address. The number of characters
in a string s. its size. is given by *s. For example. *greeting is 11 and *address is O.
Icon uses the ASCII character set. extended to 256 characters. There are
escape conventions, similar to those of C. for representing characters that cannot be keyboarded.
Strings also can be read in and written out, as in

line :

= read()

and

write(line)
Strings can be constructed by concatenation, as in

= "("

element ;
II readO II ")"
If the concatenation of a number of strings is to be written out. the write function
can be used with several arguments to avoid actual concatenation:
write(" (" ,readO. I')")
Substrings can be formed by subscripting strings with range specifications
that indicate. by position. the desired range of characters. For example.

middle := line [10: 20]
assigns to middle the string of characters of line between positions 10 and 20.
Similarly.

write(line [2])
writes the second character of line. The value 0 is used to refer to the position
after the last chara.cter of a string. Thus

write(line [2:0])
writes the substring of line from the second character to the end. thus omitting
the first character.
An assignment can be made to the substring of string-valued variable to
change its value. For example.

line[2] := " ... "
replaces the second character of line by three dots. Note that the size of line
changes automatically.
, There are many functions for analyzing strings. An example is

-3flnd(s1. s2)
which produces the position in s2 at which s1 occurs as a substring. For example,
if the value of greeting is as given earlier,

find(" or" • greeting)
produces the value 8. See Section 4.2 for the handling of situations in which s1
does not occur in s2 or in which it occurs at several different positions.

3. Character Sets
While strings are sequences of characters, csets are sets of characters in
which membership rather than order is significant. Csets are represented
literally using single enclosing quotation marks, as in

vowels := 'aeiouAEIOU'
Two useful built-in csets are &lcase and &ucase, which consist of the lowercase
and uppercase letters, respectively. Set operations are provided for csets. For
example,

letters := &lcase ++ wcase
forms the cset union of the lowercase and uppercase letters and assigns the
resulting cset to letters, while

consonants := letters -- 'aeiouAElOU'
forms the cset difference of the letters and the vowels and assigns the resulting
cset to consonants.
Csets are useful in situations in which anyone of a number of characters is
significant. An example is the string analysis function

upto(c, s)
which produces the position s at which any character in c occurs. For example,

upto(vowels. greeting)
produces 2. Another string analysis function that uses csets is

many(e.s)
which produces the position in s after an initial substring consisting only of characters that occur in s. An example of the use of many is in locating words. Suppose, for example. that a word is defined to consist of a string of letters. The
expression
write (line [1: many{letters.line)])
writes a word at the beginning of line. Note the use of the position returned by a
string analysis function to specify the end of a substring.

4. Expression Evaluation
4.1. Conditional Expressions
In Icon there are conditional expressions that may succeed and produce a
result, or may fail and not produce any result. An example is the comparison
operation
i

>

j

which succeeds (and produces the value of j) provided that the value of i is

-4-

greater than the value of j, but fails otherwise.
The success or failure of conditional operations is used instead of Boolean
. values to drive control structures in Icon. An example is
If i

>j

thenk :

=i

else k :

=j

which assigns the value of i to k if the value of i is greater than the value of j. but
assigns the value of j to k otherwise.
The usefulness of the concepts of success and failure is illustrated by
find(s1. 82), which fails if s1 does not occur as a substring of 82. Thus
if i := find(" or" •line) then write(i)

writes the position at which or occurs in line, if it occurs, but does not write a
value if it does not occur.
Many expressions in Icon are conditional. An example is read(), which produces the next line from the input file, but fails when the end of the file is
reached. The following expression is typical of programming in Icon and illustrates the integration of conditional expressions and conventional control structures:

=

whil.e line : readO do
write(line)
This expression copies the input tile to the output file.
If an argument of a function fails, the function is not called, and the function
call fails as well. This "inheritance·' of failure allows the concise formulation of
many programming tasks. Omitting the optional do clause in while-do, the previous expression can be rewritten as

while ·wrtte(readO)
4.2. Generators
In some situations, an expression may be capable of producing more than
one result. Consider

=

sentence : "Store it in the neighboring harbor"
lind(" or" • sentence)
Here or occurs in sentence at positions 3, 23, and 33. Most programming
languages treat this situation by selecting one of the positions, such as the first.
as the result of the expression. In Icon, such an expression is a generator and is
capable of producing all three positions.
The results that a generator produces depend on context. In a situation
where only one result is needed, the first is produced, as in
i := find(" or" • sentence)

which assigns the value 3 to i.
If the result produced by a generator does not lead to the success of an
enclosing expression, however, the generator is resumed to produce another
value. An example is
if (i := find("or". sentence»

> 5 then write(i)

Here the first result produced by the generator, 3, is assigned to i. but this value
is not greater than 5 and the comparison operation fails. At this point, the generator is resumed and produces the second position, 23, which is greater than 5.

-5The comparison operation then succeeds and the value 23 is written. Because of
the inheritance of failure and the fact that comparison operations return the
value of their right argument, this expression can be written in the following more
compact form:
write(5

< tind("or". sentence»

Goal-directed evaluation is inherent in the expression evaluation mechanism
of Icon and can be used in arbitrarily complicated situations. For example.
find("or". sentence1)

= find("and". sentence2)

succeeds if or occurs in sentence1 at the same position as and occurs in sentence2.
A generator can be resumed repeatedly to produce all its results by using
the every-do control structure. An example is
every i := find("or". sentence)
do write (i)
which writes all the positions at which or occurs in sentence. For the example
above, these are 3. 23. and 33.
Generation is inherited like failure. and this expression can be written more
concisely by omitting the optional do clause:
every write(tind("or". sentence»
There are several built-in generators in Icon. One of the most frequently used
of these is
i to j

which generates the integers from i to j. This generator can be combined with
every-do to formulate the traditional for-style control structure:
eve~)k := i

to j do

Note that this expression can be written more compactly as
every r(i to j)
There are a number of other control structures related to generation. One is
alternation.

e:zprl I e:rpr2
which generates the results of exprl followed by the results of e%]YT"2. Thus
every write(tind("or". sentence!)

I write(" or' ,• sentence2)

writes the positions of or in sentence1 followed by the positions of or in sentence2. Again. this sentence can be written more compactly by using alternation
in the second argument of find:
.
every write(" or" • sentence1

I sentence2)

Another use of alternation is illustrated by

(i

I j I k)

= (0 I 1)

which succeeds if any of i, j. or k has the value 0 or 1.

5. String Scanning
The string analysis and synthesis operations described in Sections 2 and 3
. work best for relatively simple operations on strings. For complicated operations, the bookkeeping involved in keeping track of positions in strings becomes
burdensome and error prone. In such cases. Icon has a string scanning facility
that is analogous in many respects to pattern matching in SNOBOL4. In string
scanning, positions are managed automatically and attention is focused on a
current position in a string as it is examined by a sequence of operations.
The string scanning operation has the form

s ? erpr
where s is the subject string to be examined and e:qyr is an expression that performs the examination. A·position in the subject. which starts at 1. is the focus of
examination.
Matching functions change this position. One matching function. move(i).
moves the position by i and produces the substring of the subject between the
previous and new positions. If the position cannot be moved by the specified
amount (because the subject is not long enough). move(i) fails. A simple example
is

line ? while write(move(2»
which writes successive two-character substrings of line, stopping when there are
no more characters.
Another matching function is tab(i). which sets the position in the subject to
i and also returns the substring of the subject between the previous and new positions. For example,

line ?·if tab(10) then write(tab(O»
first sets the position in the subject to 10 and then to the end of the subject. writing line[10:0]. Note that no vcilue is written if the subject is not long enough.
String ancilysis functions such as find can be used in string scanning. In this
context, the string that they operate on is not specified and is taken to be the
subject. For example,

line ? while write(tab(find("or"»)
do move(2)
writes cill the substrings .of line prior to occurrences of or. Note that find produces a position. which is then used by tab to change the position and produce
the desired substring. The move(2) skips the or that is found.
Another example of the use of string ancilysis functions in scanning is

line ? while tab(upto(letters» do
write(tab(many(letters»)
which writes all the words in line.
As illustrated in the examples above, any expression may occur in the scanning expression. Unlike SNOBOL4. in which the operations that are allowed in pattern matching are limited and idiosyncratic, string scanning is completely
integrated with the rest of the operation repertoire of Icon.

-7-

6. Structures
6.1. Lists
While strings are sequences of characters, lists in Icon are sequences of
values of arbitrary types. Lists are created by enclosing the lists of values in
brackets. An example is

carl := ["buick". '~skylark". 1978.2450]
in which the list carl has four values, two of which are strings and two of which
are integers. Note that the values in a list need not all be of the same type. In fact,
any kind of value can occur in a list -even another list, as in

inventory := [carl. car2. carS. car4]
Lists also can be created by

a := list(i. x)
which creates a list of i values, each of which has the value x.
The values in a list can be referenced by position much like the characters in
a string. Thus

carl[4] := 2400
changes the last value in carl to 2400. A reference that is out of the range of the
list fails. For example,

write(carl[5])
fails.
The values in a list a are generated by !a Thus

every write(!a)
writes all the values in a.
Lists can be manipulated like slacks and queues. The function push(a~ x)
adds the value of x to the left end of the list a. automatically increasing the size of
a by one. Similarly, pop(a) removes the leftmost value from a. automatically
decreasing the size of a by one. and produces the removed value.
A list value in leon is a pointer (reference) to a structure. Assignment of a
structure in Icon does not copy the structure itself but only the pointer to it.
Thus the result of

demo := carl
causes demo and carl to reference the same list. Graphs with loops can be constructed in this way. For example.

nodel := ["a"]
node2 := [nodel. "b"]
push(node 1, node2)

-6constructs a structure that can be pictured as follows:

nodel

. ->a--.

node2

I I
'--bc::-'

6.2. Tables
Icon has a table data type similar to that of SNOBOL4. Tables essentially are
sets of pairs of values, an entry value and a corresponding assigned value. The
entry and assigned values may be of any type, and the assigned value for any
entry value can be looked up automatically. Thus tables provide a form of associative access in contrast with the positional access to values in lists.
A table is created by an expression such as

symbols := table(x)
which assigns to symbols a table with the default assigned value x. Subsequently,
symbols can be referenced by any entry value, such as

symbols ["there"] : = 1
which assigns the value 1 to the thereth entry in symbols.
Tables grow automatically as new entry values are added. For example, the
following program segment produces a table containing a count of the words that
appear in the input tile:
lfOrds := table(O)
while line := readO do
line ? tab(upto(letters» do

words[tab(many(letters»] +:= 1

Here the default assigned value for each word is 0, as given in table(O), and +:= is
an augmented assignment operation that increments the assigned values by one.
There are augmented assignment operations for all binary operators.
Tables can be converted to lists, so that their entry and assigned values can
be accessed by position. This is done by sort(t), which produces a list of twoelement lists from t, where each two-element list consists of an entry value and
its corresponding assigned value. For example,

wordlist : = sort(words)
every pair := !worellist do

write(pair[l].

II

:

".

pair[2D

writes the words and their counts from words.

7. Procedures
An Icon program consists of a sequence of procedure declarations. An example of a proce dure de claration is

procedure max{i. j)
if i

>j

then return i else return. j

end
where the name of the procedure is max and its formal parameters are i and j.

-9The return expressions return the value of i or j, whichever is larger.
Procedures are called like built-in functions. Thus

k := max(*sl. *82)
assigns to k the size of the longer of the strings s1 and s2.
A procedure also may suspend instead of returning. In this case, a result is
produced as in the case of a return, but the procedure can be resumed to produce other results. An example is the following procedure that generates the
words in the input file.

procedure genword()
local line. letters, words
letters := &lcase ++. &ucase
while line : = read() do
line? while tab(upto(letters» do
word := tab(many(letters»
suspend word
J

t

end

The braces enclose a compound expression.
Such a generator is used in the same way that a built-in generator is used.
For example

every word := genword() do
if tlnd("or". word) then write word
writes only those words that contain the substring or.

B. .An Example
The following

progr~m

sorts graphs topologically.

procedure mainO
local sorted. nodes. arcs. roots
while nodes : = readO do ~
arcs := readO
sorted :

:#
:#
:#
:#

get next node list
get arc list
sorted nodes
nodes without predecessoli
while *(roots := nodes -- snodes(arcs» > 0 do t
sorted II: = roots
:# add to sorted nodes
nodes --:= roots
:# delete these nodes
arcs := delarcs(arcs. roots)
:# delete their arcs
J
if *arcs = 0 then write(sorted)
# successfully sorted
else write(" graph has cycle")
:# cycle if node remains

= ""

J

end

-10-

procedure snodes(arcs)
local nodes
nodes :
arcs ? while move(l) do I # predecessor
move (2)
# skip "_>u
nodes 11:= move(l) II successor
move(l)
II skip ";"
J
return nodes

= ""

end
procedure delarcs(arcs. roots)
local newarcs, node
newarcs : = ""
arcs ? while node := move(l) do l II get predecessor node
if many(roots.node) then move(4)
# delete arc from root node
else newarcs 11:= node II move(4) # else keep arc

J

return newarcs
end

Graph nodes are represented by single characters with a list of the nodes on one
input line followed by a list of arcs. For example, the graph

--------------- .
I

I

t

a------>b------>c

tit
I
I
I
I
t
I

d------>e-------'

is given as

abcde
a->b;a->c;b->c;b->e;d->a;d->e:e->c:
for which the output is
dabec

The nodes are represented by csets and automatic type conversion is useQ to
convert strings to csets and vice versa. Note the use of augmented assignment
operations for concatenation and in the computation of cset difierences.

Acknowledgement
Icon was designed by the the author in collaboration with Dave Hanson. Tim
Korb. Cary Coutant, and Steve Wampler. The current implementation is largely
the work of Cary Coutant and Steve Wampler with recent contributions by Bill
Mitchell. Dave Hanson and Bill Mitchell also made several helpful suggestions on
the presentation of material in this paper.

-11-

References
Griswold, Ralph E., Poage, James F., and Polonsky, Ivan P. The SNOBOL4 Progra.mming Langua.ge, second edition. Prentice-Hall. Inc., Englewood ClitIs,
New Jersey. 1971.
2. Kernighan, Brian W. and Ritchie, Dennis M. The C Programming La.nguage .
. Prentic.e-Hall, Inc., Englewood ClitIs, New Jersey. 1978.
.
3. Griswold, Ralph E. Differences Between Versions 2 and 50/ icon. Tephnical
Report TR 83-5, Department of Computer Science, The University of Arizona .
. 1983.
4. Griswold, Ralph E. and Griswold, Madge T. The Icon Programming Language.
Prentice-Hall, Inc., Englewood .cliffs, New Jersey. 1983.
1.

Release 5g of Icon
Release 5g orlcon is an implementation of Icon that runs on both PDP-11 s and VAXs under
the UNIX * opera~ing system. This document is a brief summary of this release.

Changes
• System configuration is now performed by a shell script rather than having the
installer manually edit anumber of files.
• Interpretable rues are made to appear to be executable on both the VAX and the PDP11.
• The &output and &errout output streams are now line buffered by default. This provides a substantial performance improvement for programs that generate a large
amount of terminal output.
• There are several language extensions to the Icon language that can be optionally
includedinasystem.
• Several performance enhancements have been made to various components of the
system. Anumber of minor bugs have been fixed.

KnownBugs·
This list ennumerates all known bugs in Release 5g Icon. If you find a bug that is not in this
list, please contact us.
• The translator does not detect arithmetic overflow in conversion of numeric literals.
Verylarge numeric literals mayhave incorrect values.
• Integer overflow on multiplic ation and exponentiation are not de tected during execution. This may occur during type conversion.
• Line numbers may be wrong in diagnostic messages related to lines with continued
quoted literals.
• Program malfunction mayoccur if display() is usedinaco-expression.
• In some cases, trace messages may show the return of subscripted values, such as
&null [2]. that would be erroneous if theywere dereferenced.
• Filenames are truncated to 14charactersbyUNlX. If such a truncation deletes part of
theterlninating .icnofaftlethatisinputtothe translator. mysteriousdiagnosticm essagesmayoccurduringlinking.
• On PDP-lls. list blocks can contain no more than 4090 elements. List blocks are
created when the Ust() function is called. when literallists are specified, and when the
son.() function converts a table in to a list. It should be noted that it is pos si ble for a list
togrowtobeyond4090elements; the limitation is only upon the size 0 fthelistwhenitis
created.
•UNIX is eo trade!!'l.a.rk of Bell Laboratories,

-1-

.. 2• There is a bug in the 4.1bsd fopenO routine that under certain conditions returns a
PII:.E poiuler-tbat is'-uot-of I ange when one tries t1) npe!1 too many files. On systems
where this bug is present. it may manifest itself in the form of runtime Error 304 when
onetriestoopentoomanyfiles. (On4.1bsdsystemsthislimitisusually20files.)
• If one has an expression like x:= create ... in a loop. and xis not a global variable. the
unreferenceable expression stacks generated by each successive create operation
are not garbage collected. This problem can be circumvented by making x a global
variable or by assigning a value toxbefore the create operation. e.g .• x:= &null; x:=

create ....
• Overflow of a co-expression stack due to excessive recursion is not detected and may
cause mysterious program malfunction.
.
• The garbage collector was designed for machines with small address spaces and as
such is not well-suited for machines like the VAX. No empirical studies have been
made. but it is suspected that performance of the garbage collector can be improved
substantially on the VAX. In particular. if the user attempts to create a very large data
object that will not fit into memory, (such as a million-element list). it takes the SY5temaninordinatelylongtimetodeterminethattheobjectcannotbeallocated.

March 14. 1983
RalphE. Griswold
WilliamH. Mitchell

-2-

Installation and Maintenance Guide for Release 51 of Icon
This document describes how to install Release 5g of the Icon programming
language. The installation procedure is simple; it requires the distribution tape to be
unloaded onto the target machine. the setting of site specific constants. and the
recompilation of the Icon system itself. This document also contains information
that may be of use to maintainers ofIcon systems.
1. System Requirements
This distribution of Version 51con is targeted for VAX-lls and PDP-11s (with
separate instruction and data spaces) running the UNIX* operating system. This distribution package has been tested under V7 and 4.1bsd, and no problems should be
encountere d when installing Ie on under one of thes eversions of UNIX.
When the systemis unloaded. it requires about 1200 kilobytes of disk space. During recompilation. a total of 3000 kilobytes is required. Once the system has been
built, it is possible to delete the source code. Such a configuration requires 900 kilobytes of disk space. These figures vary slightly depending upon the logical organization of a particular disk.

2. InstallationProcedure
2.1. Unloading the DistributionTape
The system is distributed as a tar archive on magnetic tape. The tarhierarchyis
rooted at the directoryv5g. Mount the distribution tape and do a cd to the directory
that you wish to hold the system hierarchy.
The precise ta.r command to unload the distribution tape depends on the local
environment. If you are on a VAX and the distribution tape density is 1600 bpi, the following command should e xtract the contentsoftbetape:
tar x

OnaPDP-ll witba1600bpidistributiontape, use:
tarxf /dev/rmW

For example, if you want the system to reside at lusr licon/wg on a VAX. you might
type:
ed/wtr
mkdiricon
cd icon
tar x

2.2. System Configuration
Note: File names used in the following sections are usually relative to the root
directory for the leon hierarchy. For example, if the Icon system is unloaded as
described above. the root directory is /wrr licon/wI. and the file name

-2-

int/bin/llakeftlerefers to Iwrrlicon/v5g/int/bin/Makefile.
The installer must perform a site-specific configuration of the Icon system. This
configuration is accomplished the shell script inti bin I icon-setup. icon-setup
accepts a number of parameters and modifies several source rues to produce a
ready-to-compile Icon system tailoredas specified by the parameters.
icon-setuphas the following synopsis:
icon-setup
~-pdp11-hoststring

[-hzra.te] [-nofp] [--ext] [-directex]
-ibinlibra.ry directory/or the /coninte7pTeter]
-cbinlibra.rydirectory/orthe iconcompiler]
-iconxlocationo/the Iconinterpreter]

l

The parameters have the following meanings:
-vax and -pdp11
These are mutually exclusive options that control the selection of machine
dependent portions ofcode. Select one as appropriate foryourmachine.
-host string
The Icon system has a keyword, &host, whose value should be the name of the
host machine where the system is running. On some systems, notably 4.2bsd,
System Ill. and System V, it is possible to determine the name of the system at
runtime via a system call. On other systems. 4.1bsd for example, the file
lusr/includelwhoami.hcontains the name of the host in a#define statement.
If neither of these methods is available, or one wishes to pick an arbitrary string
for &host, that can be done. Ifyouareon4.2bsd, specifygethostf()rstring, this
will cause the gethostna.me (2) function to be used. If you are on System III, System V, or some other system that supports the una.me(2) system call, specify
unamefor string. Uyou are on a system with a lusr I include Iwhoami.hfile that
has a #detine for sysname, then specify whoami for stTing. If none of these are
available on your machine, orifyou want to give &chostsome value besides that of
the machine name, specify an arbitrary string (you may need quotes around ~t)
forstring. for example: -host UNIX.

-hzra.te
This parameter spe cities the cycle rate of the electrical environment you are in.
The rate defaults to 60Hz andyou only need tospecify-hzifyouarenotina60Hz
electrical environment. If the rate is incorrect, the value of the &time keyword
will be wrong.
-nofp
Specify-nofpifyouareonaPDP-llthatdoesnothavefioatingpointhardware.
-di.rectex
Specify this if you are on a 4.1bsd or later system. This option causes the use of a
feature of the exec(2) system call to make interpretable files directlyexecutable.

--ext
Enables a number of extensions to standard Version 5 as described in [4]. The se
features may be of interest to persons wishing to experiment with extensions to
Icon. However, the extensions are not supported.
-ibin dire c tory and -cbindirectory
The directories inti bin and cmp/bin contain executable versions of the Icon
translator. the Icon linke r, and various libraries. The path names of these directories are built intoicont and wonc, the programs that control the translation of
Icon programs. By default. the fully qualified names of inti bin and cmp/bin are

-3-

used for -ibin and -cbin respectively. Specifying -ibin and/or -cbin causes
icontand/oriconctousethe specified directory as its library direct ory. Ifalternate directories are specified, after the Icon systemis built, copy all of the files in
int/binand/oremp/binintothespecifieddirectories.
-tconxinterpreter-location
By default, the interpreter-location is the fully qualified name of int/bin/ieonx.
If -thin is specified, then interpre ter-location defaults to ibin-d:i:rectory /'ieonx.
If the .fully qualified name of ieonxis longer than 32 characters and you are on a
VAXrunning4.!bsd. consultSection3.! to determine what tospecifyfor-:ibin.
Before ieon-setup modifies a file, it copies a generic version of the file into place .
and works on it. Thus. ieon-setup can be run a number of times and only the last run
has any lasting effect. ieon-setup is like any other UNIX command and thus all of its
argumentsmustbespeciftedononecommandline.
For example. if you are ona VAXrunning4.1bsd, allyouneedis
icon-setup -vax -d.ireetex -host wboami
If you have a PDP-I! running V7, you don't have a hardware floating point unit, and you
want&hostto be"UnixVersion7", youshoulduse

icon-setup -pdpll-nofp -host "UnixVersion T'
Suppose you are on a VAX running System V. you have a 50 hz electrical environment.
you wish the library directories for the interpreter and the compiler to be
lusr/lib/ieon/interp and /usr/lib/icon/comp respectively, and the Icon interpreter to reside at /usr /bin/ieonx. You also wish to include the language extensions.
You wouldneed:
icon-setup ...,ax: -hz 50 -1!xt -host uname -ibin /usr /lib/icon/interp
-chin /usr llib/iconl eomp -ieonx /usr Ibin/ieonx
Note that the last example must be entered as one logical command line.
2.3. System Compilation
Thisdistributionoflconcontainsnoexecutablebinaryfilesandnoobjectfiles. so
the system must be completely recompiled from the source. After you have run
icon-setup. you are ready to compile the system. Issuing a m.alce command in int/bin
or cmp/bin completely rebuilds the interpreter or the compiler, respectively. We
recommend that you build the interpreter first and then if there are no problems,
proceed to the compiler.
The complete system constructionprocess is:

cdv5g
int/bin/icon-setup appropriate arguments
cdint/bin
make
cd .. / .. /cmp/bin
make
At this point. you should have a working Icon system. The samples directory contains programs and associated test data. !fyou desire tot est the system, consult the
tile samples IReadme.
You may wish to place a copy tnt/bin/icont and cmp/bin/iconc in a public
directory such as lusr/bin or lusr/local to provide general user access to Icon.
docs/icont.l and docs/iconc.! are ma.n pages for i.cont a.nd iconc. you may wish to
copy the appropriate set into /usr /man/man1. One e you are sure that the system is

-4-

working, you can issue the command make clean-all in int/bin and cmp/bin to
remove all non-source tiles from the source directories.

3. Special Installation Considerations
9.1. Di.rectExecutionof Interpretable rues
When an Icon program is processed by the interpreter translator and linker
using the icont command. the result is a tile containing ope odes and data in a format
that the Icon interpreter understands. Rather than having the user "execute" this
interpretable tile by running the Icon interpreter with the file as an argument, the
Icon system uses one of two methods to make the interpretable tiles appear to be
directly exe cutable.
In4.lbsd{andlater4.nbsd} systems, a feature ofexec(2) systemcallcan be used
to enable the interpretable file produced by the linker to appear to be directly executable. When exec is called with aflle to execute, it examines the first two characters
of the file. If the first two characters are #!, exec assumes that the next argument on
the line is the name of a program for which the file is to serve as input. The program
then is executed with the named file (the file that is being "executed") as its argument. Thus, instead of having to run the Icon interpreter with the interpretable file as
input, the interpretable file can be executed directly.
Analternativemethodisusedonsystemswhoseexec{2} systemcalldoesn'thave
this feature. An executable file is prep ended to the data used by the interpreter. The
executable portion of the file will merely run the Icon interpreter with the file itself
and anysupplied arguments as the arguments for the interpreter.
If -di.rectex is specified for icon-setup. the former method will be used, otherwise, the latter method will be used. The first method is preferable in that the interpretable files are smaller and they start executing more quickly.
There is a potential complication in using the first method. The 4.1bsd exec(2)
system c all imposes a length limitation of 32 characters on the name of the program
to be run. If the name exceeds 32 characters, execution of the interpretable file fails.
For example, suppose the Icon interpreter (iconx) on a system is located' at
I USC' I esc I local I icon 1v5g lint I bin liconx. This path name is long er than 32 charac~
ters, and is thus unsuitable for inclusion in interpretable files. One way to solve the
problem is to link lusr/csc/local/icon/v5g/int/bin/iconxto lusr/local/iconx,
and have interpretable files reference lusr/local/iconx. You may need to employ a
similar solution on your system. Two things need to be done. First, find a filesystem
location where a copy of int/bin/iconx can be referenced with a fully qualified path
name that is no more than 32 characters long. Second, when you configure the system using icon-setup, specify the new location oficonxusing the -iconxoption. For
example:
-icon~tup other

arguments -iconx: lusrIlocal/iconx

Be sure to place a copy of iconx in the specified location after the system is completelybuilt. It is also possible togetaround this problem by not specifying -directex
and having Iconprepend the executable header on interpre table files.

9.2. PDP-1l Systems without Separate I/DSpaces
This version is designed to run on PDP-l1s with separate instruction and data
spaces. Some persons have decreased the sizes of various internal structures and
have brought up Icon on machines without separate liD spaces, but only small programs can be run. These adaptations to non-l/D machines were done with an earlier
version ofIcon and we do not have details of the changes required.

-54. Assortedlnformation
The following sections contain information that is not neede d during the installation process. but may be helpful in understanding the organization of the system.

4.1. SystemLayout
Thelconsystemhasfourtop-leveldirectoriesbranchingotIfromv5g:
docs
System documentation and man page s.
samples Sarnple programs and associated data.
book
Source codeforprocedures appearingin[1].
int
Source code hierarchy for the Icon interpreter.
cmp
Source code hierarchy for the leon compiler.

4.2. SystemComponents
The following directories contain various components of the Icon system and
branchotIfrombothcmpandint. (TbedirectoryiconxonlyappearsininL)
tran
Soure code for the Icon translator.
link
Source code for the Icon linker.
Headerfllesthatareincludedinothersourcefiles.
h
functions Source c ode for the leon builtin functions.
lib
Source code for runtime support routines that are directly callable from
anlcon program.
operators Sourcecodeforthelconoperators.
rt
Source code forthe Icon runtime system.
iconx
Source code forthe Icon interpreter proper.
Libraries and executable versions of various system components. The
bin
source for programs that c ontrollcon translation also resides here.

4.3. Source IDe linking
The bulk of the source code for the Icon compiler and interpreter is very similar
and in most cases, analogous files are linked between the cmp and inthierarchies. For
example. int/functions/write.cis linked to cmp/functions/wrlte.c. Insome cases.
preprocessor control statements are used to select portions of code in a particular
tile depending upon whether the compiler or interpreter is being compiled. Occasionally, files that are linked may not be in analogous directories, for example.
int/iconx/starLs and int/iconx/init.c are linked to cmp/rtlstart.s and
cmp/rt/init.c respectively. The only directories where some analogous source files
are not linked are int/link and cmp/liDk. In addition, Makefiles are linked when possible.
Because the same source is used to produce versions of Icon on both VAXs and
PDP-l1s. the portions of the code that are machine dependent are bracketed with
preprocessor control statements to select sections appropriate for each machine.
This is primarily used for assembler source files, but also is used in a few cases for C
sourceffies. In some cases where differences are extreme {as for assembler flles} ,the
section of code for the VAX appears in its entireity and is followed by the code for the
PDP-l1 in its entireity.
If you decide to make sourc e modific ations, check link counts to be sure that you
are not modifying more files than you think are, or less files than you think you are.

-64.4. Recompilationof System Components
Execution of the make command while in any source code directory causes the
system component in that directory to be rebuilt. Doing a m.aJce in cmp/bin or
int/bincauses the appropriate system to berebuilt.
The directories iconx, tran. and link each contain code for a single program.
Doing a make in any of these directories causes the particular program to be remade.
The resulting program may then be copied into the appropriate bin directory
(cmp/binor int/bin).
The directories functions, lib, operators, and rt each contain source code for a
part of the Icon runtime system. The Icon interpreter. iconx, is formed by linking all
the runtime subroutines tog ether with the routines in int/iconx. Icon programs processed by the Icon compiler arelinked together with a library ( cmp/bin/libLa) of the
runtime system subroutines. When changes are made to the interpreterruntimesystern. all aftected libraries must be rebuilt and then iconxmust be rebuilt. For exampIe. if the files int/operators/bang.c and int/functions/read c have beenmodifled.
the following sequence of commands rebuilds the interpreter.
cd int/functions
make
cd .. 1 operators
make

cd .. /iconx
make
cp iconx .. /bin

# copy new version of interpreter to int/bin

Alternatively. performing a make in int/bin has the same effect. Similarly, if the
changes have been made in the compiler rather than in the interpreter. these commands rebuild the compiler:
cd cmp/functions
make
cd .. / operators
make
cd .. /bin
make lib

# rebuild and randomize libLa

If disk space is critical on your system. it is possible to delete all v5g directories
except for int/hin and cmp/bin, and retain a functional leon system. That
configuration requires about 500 kilobytes of disks pace.
4.5. PDP-I1 yacc modi.ti.cations for the IconTranslator
You onlyneed to be concerned with this section if you are going to modifythe Icon
grammar, contained in the file cmp/tran/ucon.g. The version of yacc distributed
with VAX systems is large enough to build the Icon parser [3]. but it may be necessary
to build a version ofyacc with larger parameters if you are on. a PDP-I!. The following
defined constants in the file dextern (in the yacc source directory) should be given
the values listed below. Larger values are acceptable for all these constants, but are
not necessary.

-7-

# ifdef HUGE
# define ACTSIZE 3000

# define MEMSIZE 6000

# define NSfATES 300

# define NTERMS 127
# define NPROD 200
# define NNONTERM: 100
# define TEMPSIZE 1200
# define CNAMSZ 4100
# define LSETSIZE 200
# define lISETSIZE 200
Dendi!

The constant HUGE should be defined instead of MEDIU1l at the end of the file

yacc/files.
Thenyaca should be rebuilt.

4.6. Obtaining Source Code listings
Execution of the command

make Listall
in ~y of the directories except bin produces listings of all source files from that
directory on standard output. Use the command

make List
to obtain listings of all files that have been altered since the last make List or make
Listall

Electronic Mail andProblemReporting
A mailbox has been established to facilitate communication with us, should you
have problems or questions. Usethefollowing addresses for electronic mail:

icon-project.arizona@rand-relay (CSNET and ARPANET)
arizona! icon-proj ect
(Usenet and uucpnet)
We currently have uucp connections established through gi, mcnc, ucbvax, and
utah~s.

If you encounter any problems with the leon system, or if you have any suggestionsaboutIconingeneralortheinstallationprocessinparticular.pleasecontactus.
If you do not have access to electronic mail facilities. please use the Trouble Report
Forms supplied in the distribution package or call Ralph Griswold at 602-626-1829
(602-621-6609 after April 8. 1983).

References
1. Ralph E. Griswold and Madge T. Griswold, The Icon Programming Language.
Prentice-HallInc., EnglewoodClitIs, NewJ ersey. 1983.
2. Tape Directory Jor RelerJ..se 5g 0/ Icon. Department of Computer Science, The
University of Arizona. March 1983.
3. Coutant. Cary A. and Wampler. Stephen B. A Tour Through the Clmplementationo/
Icon; Version 5. Technical Report TR 8I-11a. Department of Computer Science. The
University of Arizona. December 19B 14. RaiphE. Griswoidand WilliamH. Mitchell. E:cperimentalEzter..sior..sto Icon. Department of Computer Science. The University ofArizona. March 1983.

-8RalphE. Griswold (ralph.arizona@rand-relay. arizona! ralph)
WilliamH. Mitchell (whm.arlzona@rand-relay. arlzona!whm)
March 12. 1983

Notes on the Icon "Tour" (TR 81-11a)
A technical report. TR 81-11a, describing the implementation of Icon, is enclosed with
Release 5g. This report is based on the original Version 5 implementation done for the
PDP-11. While most of the information in this report is machine independent. the machine
dependent sections refer to the PDP-11. A new report is in preparation and will be available at some point in the future.
One important difference related to external functions should be noted. Since the
4.1bsd C compiler does not initialize unions, procedure blocks for external functions must
be declared and initialized using the b iproc structure rather than the b...,proc structure
as shown in TR 81-11a. {Procedure blocks are declared after the body of the function.} The
b iproc structure is identical to the b-Pl"OC structure except that it uses the sdescrip
structu~e rather than the descrip structure {descrip has a union. sdescrip does not} to
hold the name of the procedure. The b iproc structure should only be used for declaration and initialization of data blocks for functions.

March 10, 1983
Ralph E. Griswold
William H. Mitchell

Experimental Extensions to Version 5 of Icon
Ralph E. Griswold and William H. Mitchell
Department of Computer Science, The University of Arizona
March 3, 1983

A number of experimental extensions have been made to Version 5 of Icon.
This version is called Version 5x for reference.
The extensions in Version 5x, which are described below, are upwardcompatible ones and should not inteti'ere with programs that run properly on
Version 5.
1. POCO Invocation Syntax
Version 5x contains the procedure invocation syntax that is used for
programmer-defined control operations (see TR 82-8 and TR 82-16).
In this syntax, when braces are used in place of parentheses to enclose an
argument list, the arguments are passed as a list of co-expressions. That is,

pl. · · J
is equivalent to
P([ create. create, • create ])
There is always at least one co-expression in the list:

pH
is equivalent to

l:

P([create &null])
2. InvocationVia String Name
In the Version 5xinterpreter (but not compiler), a string-valued expression that
corresponds to the name of a procedure or operation may be us ed in place of the procedure or operation in an invoc ali on expression. For example,

"image" (x)
produces the same call as

image (x)
and
U.J'(i,j)

is equivalent to

-2-

i-j

In the case of operations. the number of arguments determines the operation.
Thus
1f.J f

(i)

is equivalent to

-t.
Since to-by is an operation. despite its reserved-word syntax. it is included in this
facility with the string name .... Thus
....... (1.10.2)
is equivalent to

1 tol0by2
Similarly. range specifications are represented by":". sothat

":"{s.i.j)
is equivalent to

s[i:j]
Defaults are not provided for omitted or null-valued arguments in this facility.
Consequently.

"... "(1.10)
results in a run-time errorwhenit is evaluated.
The subscripting operationaisoisavailablewiththestringname []. Thus
If []'I (&:lcase, 3)
producesc.
String names are available for all the operations in Icon. but nol for control
structures. Thus
"1"(,)

is erroneous.
String names for procedures are available through global identifiers. Note that
the names of functions. such as image are global identifiers. Similarly. any
procedure-valued global identifier may be used as the string name of a procedure.
Thus in
globalq

procedure mainO
q:=p

"cf("hi")
end
procedure pes)

write(s)
end

the procedure pis invoked via the giobai identifier q

-3-

3. lnteg er Sequences
To facilitate the generation of integer sequences that have no limit. the function
seq(i.j) has been added. This function has the result sequence lit i+j. i+2j. J. Omitted
or null values foriandj default to 1. Thus the result sequence for seqOis t 1.2.3. J.

MH
A Mail Handling System
for UNIX

October. 1979
Bruce Borden

The Rand Corporation
1700 Main Street
Santa Monica, CA 90406
(213) 399-0568 x 7463

CONTENTS

~........................

i

SUMMARY ...............................................•.......................................

v

PREFACE ........................................

u

•••••••••••••••••••••

Section

1. INTRODUCTION ......................................................•.................

2

2. OVERVIEW ................. .................. .............•..............................

4

3. TUTORIAL.... . . ........... .... ......... .. ........ .............. ....... ..... ... .. ... ......

6

4. DETAILED DESCRIPTION .................. .................................. ......

9

mE USER PROFILE .•.................................. ............... ...........

9

MESSAGE NAMING .. .•.... ........... ..... ............................... .........

11

OTHER MH CONVENTIONS ........ ....... ........ .............................
MH COMMANDS ................................ .....................................
COMP .............................................................................

12

DIST ..................................... ~..........................................

17

FIlE ...............................................................................

19
21
23
24
26

FOLDER . .........................................................................
FORW .............................................................................
INC ................................................................... .............
NEX'r .............................................................................
PICK ...... ..... ..... ........ ...... ... ................ ............ .................
PREY ......••.......••.. .... .••.. ........•..•.•.....•....... ..... ..••.....•....•..

14
15

27
30

PROMPrnR ............ ........................ .... ............... .. ...... .. .. .

31

REPL ..............................................................................

SEND ....................... ...•••.••..•.•••.••••.•••..•.... ...••..••... ....... ...

32
34
35
36
37

SHOW....................... ...................... ....................... .........

38

RMF ..................................................... ~.........................
RMM ...............................................................................
SCAN .............................................................................

Appendix
A. Command Summary .................................... .... ................... .. .
B. Message Format ....... ................ ........ ..................... ..................
C. Message Name BNF ...•...•.....•............•......•.. ........•...................
D. Example of Shell Com.rnands ........................ ..........................

42

REFERENCES ..................•......•.•...•.•..••••.•..•••..••••••.•..•........•....•........

43

39
40
41

PREFACE

This report describes a system for dealing with me ssag es transmitted on a computer. Such messages might originate with other users of
the same computer or might come from an outside source through a
network to which the user's computer is connected. Such computerbased message systems are becoming increasingly widely used, both
within and outside the Department of Defense.
The message handling system MH was developed for two reasons.
One was to investigate some research ideas concerning how a message
system might take advantage of the' architecture of the UNIX timesharing operating system for Digital Equipment Corporation PDP-i1 and
VAX computers. and the special features of UNIX's command-level
interface with the user (the "shen"). The other reason was to provide a
better and more adaptable base than that of conventional designs on
which to build a command and control message system. The effort has
succeeded in both regards, although this report mainly describes the
message system itself and how it fits in with UNIX.. The main research
results are being described and analyzed in a forthcoming Rand report.
The system is currently being used as part of a tactical command and
control "laboratory," which is also being described in a separate
report.
The present report. should be of interest to three groups of
readers. First, it is a complete reference manual for the users of MH
(although users outside of Rand must take into account differences
from the local Rand operating system). Second. it should be of interest
to those who have a general knowledge of computer-based message systems, both in civilian and military applications. Finally, it should be of
interest to those who build large subsystems that interface with users,
since it illustrates a new approach to such interfaces.
The MH system was developed by the :first author. using an
approach suggested by the other two authors. Valuable assistance was
provided by Phyllis Kantar in the later stages of the system's implementation. Several colleagues contributed to the ideas included in this
system, particularly Robert Anderson and David Crocker. In addition,
valuable experience in message systems, and a valuable source of
ideas, was available to us in the form of a previous message system for
UNIX called MS. designed at Rand by David Crocker.
This report was prepared as part of the Rand project entitled
"Data Automation Research". sponsored by Project AIR FORCE.

-1-

SUMMARY

Electronic communication of text messages is becoming commonplace. Computer-based message systems-software packages that provide tools for dealing with messages-are used in many contexts. In
particular, message systems are becoming increasingly important in
command and control and intelligence applications.
This report describes a message handling system called MH. This
system provides the user with tools to compose, send, receive, store,
retrieve, forward, and reply to messages. MH has been built on the
UNIX time-sharing system, a popular operating system developed for
the DEC PDP-ii and VAX classes of computers.
A complete description of MH is given for users of the system. For
those who do not intend to use the system. this description gives a general idea of what a message system is like. The system involves some
new ideas about how large subsystems can be constructed. These
design concepts and a comparison of MH with other message systems
will be published in a forthcoming Rand report.
The interesting and unusual features of MH include the following:
The user command interface to MH is the UNIX "shell" (the standard
UNIX command interpreter). Each separable component of message
handling, such as message composition or message display, is a
separate cornman:l. Each program is driven from and updates a
private user environment. which is stored as a file between program
invocations. This private environment also' contains information to
"custom tailor" MH to the individual's tastes. MH stores each message
as a separate file under UNIX. and it utilizes the tree-structured UNIX
file system to organize' groups of files within separate directories or
"folders." All of the UNIX facilities for dealing with files and directories, such as renaming. copying, deleting, cataloging. off-line J?rinti~,
etc., are applicable to messages and directories of messages (folders).
Thus, important capabilities needed in a message system are available
in MH without the need (often seen in other message systems) for code
that duplicates the facilities of the supporting operating system. It
also allows users familiar with the shell to use MH with minimal effort.

-y-

1. INTRODUCTION

Although people can travel cross-country in hours and can reach
others by telephone in seconds, communications still depend heavily
upon paper, most of which is distributed through the mails.
There are several major reasons for this continued dependence on
written documents. First, a written document may be proofread and
corrected prior to its distribution, giving the author complete control
over his words. Thus, a written document is better than a telephone
conversation in this respect. Second, a carefully written document is
far less likely to be misinterpreted or poorly translated than a phone.
conversation. Third, a signature offers reasonable verification of
authorship, which cannot be provided with media such as telegrams.
However, the need for ~, accurate, and reproducible document
distribution is obvious. One solution in widespread use is the telefax.
Another that is rapidly gaining popularity is electronic mail. Electronic
mail is similar to telefax in that the data to be sent are digitized,
transmitted via phone lines, and turned back into a document at the
receiver. The advantage of electronic mail is in its compression factor.
Whereas a telefax must scan a page in very fine lines and send all of the
black and white information, electronic mail assigns characters fixed
codes which can be transmitted as a few bits of information. Telefax
presently has the advantage of being able to transmit an arbitrary
page, including pictures, but electronic mail is beginning to deal with
this problem. Electronic mail also integrates well with current directions in office automation, allowing documents prepared with sophisticated equipment at one site to be quickly transferred and printed at
another site.
Currently, most electronic mail is intraorganizational, with mail
transfer remaining within one computer. As computer networking
becomes more common, however, it is becoming more feasible to communicate with anyone whose computer can be linked to your own via a
network.
The pioneering efforts on general-purpose electronic mail were by
organizations using the Defense Department's ARPANET.[l] The capability to send messages between computers existed before the ARPANET
. was developed, but it was used only in limited ways. With the advent of
the ARPANET, tools began to be developed which made it convenient for
individuals or organizations to distribute messages over broad geographic areas, using diverse computer facilities. The interest and
activity in message systems has now reached such proportions that
steps have been taken within the DoD to coordinate and unify the
development of military message systems. The use of electronic mail is
expected to increase dramatically in the next few years. The utility of
such systems in the command and control and intelligence environments is clear, and applications in these areas will probably lead the
way. As the costs for sending and handling electronic messags continue
their rapid decrease, such uses can be expected to spread rapidly into
other areas and, of course, will not be limited to the DoD.

-2-

-sA messase system provides tools that help users (individuals or
organizations) deal with messages in various ways. Messages must be
composed, sent, received, stored, retrieved.. forwarded. and replied to.
Today's best interactive computer systems provide a variety of wordprocessing and information handling capabilities. The message handling facilities should be well integrated with the rest of the system, so
as to be a graceful extension of overall system capability.
The message system described in this report, MH, provides most of
the features that can be found in other message systems and also
incorporates some new ones. It has been built on the UNIX timesharing system,[2] a popular operating system for the DEC PDP-ii and
VAX classes of computers. A secure" operating system similar to
UNIX is currently being developed.[3] and that system will also run MH.
This report provides a complete description of MH and thus may
serve as a user's manual, although parts of the report will be of interest
to non-users as well. Sections 2 and 3. the Overview and Tutorial.
present the key ideas of MH and will give those not familiar with message systems an idea of what such systems are like.
MH consists of a set of commands which use some special files and
conventions. Section 4 covers the information a user needs to know in
addition to the commands. The final section. Sec. 5, describes each of
the MH commands in detail. A summary of the commands is given in
Appendix A. and Appendixes Band C describe the ARPANET conventions
for messages (we expect that many users of MH will be using the
ARPANET) and the formal syntax of such messages, respectively.
Finally. Appendix D provides an illustration of how MH commands may
be used in conjunction with other UNIX facilit~es.
A novel approach has been taken in the design of MH. The design
concept will be reported in detail in a forthcoming Rand report, but it
can be described briefly as follows. Instead of creating a large subsystem that appears as a single command to the user. (such as MS[ 4]) MH
is a collection of separate commands which are run as separate programs. The file and directory system of UNIX are used directly. Messages are stored as individual files (datasets), and collections of them
are grouped into directories. In contrast, most other message systems
store messages in a complicated data structure within a monolithic file.
With the MH approach. UNIX commands can be interleaved with commands invoking the functions of the message handler. Conversely,
existing UNIX commands can be used in connection with messages. For
example. all the usual UNIX editing. text-formatting. and printing facilities can be applied directly to individual messages. MH, therefore. consists of a relatively small amount of new code; it makes extensive use of
other UNIX software to provide the capabilities found in other message
systems.
II

2. OVERVIEW

There are three main aspects of MH: the way messages are
stored (the message database), the user's profile (which directs how
certain actions of the message handler take place), and the commands
for dealing with messages.
Under MH. each message is stored as a separate file. A user can
take any action with a message that he could with an ordinary file in
UNIX. A UNIX direct.ory in which messages are stored is called a folder.
Each folder contains some standard entries to support the messagehandling functions. The messages in a folder have numerical names.
These folders (directories) are entries in a particular directory path.
described in the user profile. through which MH can find message folders. Using the UNIX "link" facility, ~t is possible for one copy of a message to be "filed" in more than one folder, providing a message index
facility. Also, using the UNIX tree-structured file system, it is possible
to have a folder within a folder. This two-level organization provides a
"selection-list" facility. with the full power of the MH commands available on selected sublists of messages.
Each user of MH has a user profile, a file in his $HOME (initial login)
directory called ". mh.profile". This profile contains several pieces of
information used by the MH commands: a path name to the directory
that contains the message folders, information concerning which folder
the user last referenced (the "current" folder), and parameters that
tailor MH commands to the individual user's requirements. It also contains most of the necessary state information concerning how the user
is dealing with his messages, enabling MH to be implemented as a set of
individual UNIX commands, in contrast to the usual approach of a
monolithic SUbsystem.
In MH. incoming mail is appended to the end of a file called. mail
in a user's $HOME directory. The user adds the new messages to his
collection of MH messages by invoking the command inc. Inc (incorporate) adds the new messages to a folder called '"inbox", assigning
them names which are consecutive integers starting with the next
highest integer available in inbox. Inc also produces a scan summary
of the messages thus incorporated.
There are four commands for examining the messages in a folder:
show, prev. next, and scan. Show displays a message in a folder, prev
displays the message preceding the current message, and next displays
the message following the current message. Scan summarizes the
messages in a folder. producing one line per message, showing who the
message is from. the date. the subject, etc ..
The user may move a message from one folder to another with the
command file. Messages may be removed from a folder by means of
the command rmm. In addition, a user may query what the current
folder is and may specify that a new folder become tQe current folder,
through the command folder.
A set of messages based on content may be selected by use of the
command pick. This command searches through messages in a folder

and selects those that match a given criterion. A subfolder is created
within the original folder, containing links to all the messages that
satisfy the selection criteria.
A message folder (or subfolder) may be removed by means of the
command rmJ.
There are five commands enabling the user to create new messages and send them: camp, d:ist, /OT'W, repL, and send. Camp provides
the facility for the user to compose a new message; dist redistributes
mail to additional addressees; /arw enables the user to forward messages; and repl facilitates the generation of a reply to an incoming message. If a message is not sent directly by one of these commands, it
may be sent at a later time using the command send.
All of the elements summarized above are described in more detail
in the following sections. Many of the normal facilities of UNIX provide
additional capabilities for dealing with messages in various ways. For
example, it is possible to print messages on the line-printer without
requiring any additional code within MH. Using standard UNIX facilities,
any terminal output can be redirected to a file for repeated or future
viewing. In general, the flexibility and capabilities of the UNIX interface
with the~user are preserved as a result of the integration of MH into the
UNIX structure.

3. TUTORIAL

. This tutorial provides a brief introduction to the MH commands. It
should be sufficient to allow the user to read his mail, do some simple
manipulations of it. and create and send messages.
A messag.e has two major pieces: the header and the body. The
body consists of the text of the message (whatever you care to type in).
It follows the header and is separated from it by an empty line. (When
you compose a message, the form that appears on your terminal shows
a line of dashes after the header. This is for convenience and is
replaced by an empty line when the message is sent.) The header is
composed of several components. including the subject of the message
and the person to whom it is addressed. Each component starts with a
name and a colon; components must not start with a blank. The text of
the component may take more than one line. but each continuation
line must start with a blank. Messages typically have "to:", "cc:". and
"subject:,. components. When composing a message, you should
include the "to:" and "subject:" components; the "cc:" (for people you
want to send copies to) is not necessary.
The basic MH commands are inc, scan, show, next, pre v, rmm,
camp. and repl. These are described below.
inc
When you get the message "You have mail". type the command
inc. You will get a "scan listing" such as:
revival of measurement work
7/13 Cas
NBS people and publications
10/ 9 Norm
question «Are there any functions
11/26 To:norm
This shows the messages you received since the last time you executed this command ( inc adds these new messages to your inbox
folder). You can see this list again. plus a list of any other messages
you have, by using the scan command.
7+
8
9

scan
The scan listing shows the message number. followed by the date
and the sender. (If you are the sender. the addressee in the litO:" component is displayed. You may send yourself a message by including
your name among the "to:" or "cc:,. addressees.) It also shows the
message's subject; if the subject is short, the first part of the body of
the message is included after the characters «.
show

This command shows the current message. that is, the first one of
the new messages after an inc. If the message is not specified by name
(number). it is generally the last message referred to by an MH command. For example,
show 5

will show message 5.

-7You can use the show command to copy a message or print a message.

shaw
show

next

>

%

will copy the message to file x.

I print will print the message, using the print command.

prell
rmm
rmm 3

will
will
will
will

show the message that follows the current message.
show the message previous to the current message.
remove the current message.
remove message 3.

camp
The camp command puts you in the editor to write or edit a message. Fill in or delete the "to:", "cc:", and "subject:" fields. as
appropriate. and type the body of the message. Then exit normally
from the editor. You will be asked "What now?". Type a carriage
return to see the options. Typing send will cause the message to be
sent; typing quit will cause an exit from camp. with the message draft
saved.
If you quit without sending the message. it will be saved in a file
. called /usr//Mail/draft (where /usr/ is your SHOME
directory). You can edit this file and send the message later. using the
send command.
camp -editor prompter
This command uses a different editor and is useful for preparing
"quick and dirty" messages. It prompts you for each component of the
header. Type the information for that component, or type a carriage
return to omit the component. After that, type the body of the message. Backspacing is the only form of editing allowed with this editor.
When the body is complete. type a carriage return followed by  «OPEN> on Ann Arbor terminals). This completes the initial
preparation of the message; from then on, use the same pro'cedures as
with camp (above).
repl
repl n

This command makes up an initial message form with a header
that is appropriate for replying to an existing message. The message
being answered is the current message if no message number is mentioned, or n if a number is specified. After the header is completed,
you can finish the message as in camp (above).
This is enough information to get you going using MH. There are
more commands. and the commands described here have more
features. Subsequent sections explain MH in complete detail. The system is quite powerful if you want to use its sophisticated features. but
the foregoing commands suffice for sending and receiving messages.
There are numerous additional c·apabilities you may wish to
explore. For example. the pick command will select a subset of messages based on specified criteria such as sender or subject. Groups of
messages may be designated, as described in Sec. V. under "Message
Naming". The 1Ue ". mh..profile" can be used to tailor your use of the

message system to your needs and preferences, as described in Sec. V,
under liThe User Profile". In general, you may learn additional features
of the system selectively. according to your requirements, by studying
the relevant sections of this manual. There is no need to learn all the
details of the system at once.

4. DETAILED DESCRIPTION

This section describes the MH system in detail, including the components of the user profile, the conventions for message naming, and
some of the other MH conventions. Readers who are generally familiar
with computer systems will be able to follow the principal ideas,
although some details may be meaningful only to those familiar with
UNIX.

THE USER PROnLE
The first time an MH command is issued by a new user, the system
prompts for a "path" and creates an MH "profile".
Each MH user has a profile which contains current state information for the MH package and, optionally, tailoring information for each
individual program. When a folder becomes the current folder, it is
recorded in the user's profile. Other profile entries control the MH
path (where folders and special files are kept), folder and message protections, editor selection, and default arguments for each MH program.
The MH profile is stored in the file "_ mh..profile" in the user's
SHOME directory. It has the format of a message without any body_
That is, each profile entry is on one line, with a keyword followed by a
colon {:} followed by text particular to the keyword.
.... This file must nat have blank lines.
The keywords may have any combination of upper and lower case. (See
Appendix B for a description of message formats.)
For the average MH user, the only profile entry of importance is
"Path". Path specifies a directory in which MH folders and certain files
such as "draft" are found. The argument to this keyword must be a
legal UNIX path that names an existing directory. If this path is
unrooted (Le., does not begin with a I), it will be presumed to start
from the user's tHOME directory. All folder and message references
within MH will relate to this path unless full path names are used.
Message protection defaults to 664, and folder protection to 751.
These may be changed by profile entries "Msg-Protect" and "FolderProtect", respectively. The argument to these key~~lords is an octal
number which is used as the UNIX file mode. 1
When an MH program starts running, it looks through the user's
profile for an entry with a keyword matching the program's name. For
example, when camp is run, it looks for a "comp" profile entry. If one
is found, the text of the profile entry is used as the default switch setting until all defaults are overridden by explicit switches passed to the
program
as
arguments.
Thus
the
profile
entry
"comp: -form standard. list" would direct camp to use the file
"standard.list" as the message skeleton. If an explicit form switch is
given to the camp command, it will override the switch obtained from
'See chmoci(I) in the UNIX Program:meT's Manual.[5]

-10the profile.
In UNIX, a program may exist under several names, either by linking or aliasing. The actual invocation name is used by an MH program.
when scanning for its profile defaults. Thus, each MH program may
have several names. by which it can be invoked, and each name may
have a different set of default switches. For example, if camp is
invoked by the name icomp. the profile entry "icomp" will control the
default switches for this invocation of the camp program. This provides
a powerful definitional facility for commonly used swi.tch settings.
The default editor for editing within camp, repl, !orw, and d.ist, is
lI/bin/ned".2 A different editor may be used by specifying the profile
entry "Editor:
The argument to "Editor~' is the name of an executable program or shell command file which can be found via the user's
SPATH defined search path, excluding the cur.·ant directory. The "Editor:" profile specification may in turn be overridden by a
"-editor " profile switch associated with camp. repl. Jorw. or
d.ist. Finally, an explicit editor switch specified with any of these four
commands will have ultimate precedence.
During message composition, more than one editor may be used.
For example, one editor (such as prompter) may be used initially, and a
second editor may be invoked later to revise the message being composed (see the discussion of camp in Section 5 for detailS). A profile
entry -next: " specifies the name of the editor
to be used after a particular editor. Thus "comp: -e prompter"
causes the initial text to be collected by prompter. and the profile
entry "prompter-next: ed" names ed as the editor to be invoked for
the next round of editing.
Some of the MH commands, such as show, can be used on message
folders owned by others, if those folders are readable. However. you
cannot write in someone else's folder. All the MH command actions not
requiring write permission may be used with a "read-only" folder. In a
writable folder, a file named "cur" is used to contain its current message name. For read-only folders. the current message name is stored
in the user's profile.
Table 1 lists examples of the currently defined profile entries, typical arguments, and the programs that reference the entries.
II.

II

Table 1
PROFILE COMPONENTS

Keyword and Argument
Path: Mail
Current-Folder: inbox
Editor: Ibin/ed
Msg-Protect: 644

MH Programs that
Use Component

All
Most

comp. d.ist. Jorw. repl
inc

SSee Ref. 6 for a description of the NED text editor.

-11Folder-Protect.: 711
: default switches
cur-: 172
prompter-next: ed

file, inc, pick·
All
Most

camp, dist, /arw, repl

Path should be present. Folder is maintained automatically by
many MH commands (see the "Context" sections of the individual com·
mands in Sec. V). All other entries are optional, defaulting to the
values described above.

1DS3AGE NAMING
Messages may be referred to explicitly or implicitly when using MH
commands. A formal syntax of message names is given in Appendix C,
but the following description should be sufficient for most MH users.
Some details of message naming that apply only to certain commands
are included in the description of those commands.
Most of the MH commands accept arguments specifying one or
more folders, and one or more messages to operate on. The use of the
word "msg" as an argument to a command means that exactly one
message name may be specified. A message name may be a number,
such as 1, 33, or 234, or it may be one of the "reserved" message
names: first, last, prev, next, and cur. (As a shorthand, a period (. ) is
equivalent to cur.} The meanings of these names are straightforward:
"first" is the first message in the folder; "last" is the last message in
the folder; "prev" is the message numerically previous to the current
message; "next" is the message numerically following the current message; "cur" (or". ") is the current message in the folder.
The default in commands that take atlmsg" argument is always
"cur" .
The word "msgs" indicates that several messages may be
specified. Such a specification consists of several message designations
separated by spaces. A message designation is either a message name
or a message range. A message range is a specification of the form
namel-name2 or namel:n, where namel and name2 are message
names and n is an integer. The first form designates all the messages
trom name 1 to name2 inclusive; this must be a non-empty range. The
second form specifies up to n messages, starting with namel if namel
is a number, or tlrst., cur, or next, and ending with namel if namel is
last or prevo This interpretation of n is overridden if n is preceded by a
plus sign or a minus sign; +n always means up to n messages starting
with namel, and -n always means up to n messages ending with namel.
Repeated specifications of the same message have the same effect as a
single specification of the message. Examples of specifications are:
157-11 22
first 6 8 next
Orst-lO
last:5

-12The message name "all" is a shorthand for llfirst-Iast". indicating
all of the messages in the folder.
The limit on the number of messages in an expanded message list
is generally 999-the maximum number of messages in a folder. However. the show command and the commands 'pick -scan' and
'pick -show' are constrained to have argument lists that are no more
than 512 characters long. (Under Version 7 UNIX this limit is 4096.)
In comolands that accept "msgs" arguments. the default is either
cur or all, depending on which makes more sense.
In all of the MH commands. a plus sign preceding an argument
indicates a folder name. Thus. +inbox" is the name of the user's standard inbox. If an explicit folder arfitument is given to an MH command.
it will become the current folder {that is. the "Current-Folder:" entry
in ". mh-profile" will be changed to this folder). In the case of the file'
and pick commands. which can have multiple output folders. a new
source folder {other than the default current folder} is specified by
"-src +folder".
II

OTHER MIl CONVENTIONS

One very powerful feature of MH is that the MH commands may be
issued from any current directory, and the proper path to the
appropriate folder{s) will be taken from the user's profile. If the MH
path is not appropriate for a specific folder or file. the automatic
prepending of the MH path can be avoided by beginning a folder or rue
name with /. Thus any specific full path may be specified.
Arguments to the various programs may be given in any order.
with the exception of a few switches whose arguments must follow
immediately, such as "-src +folder" for pick and file.
Whenever an MH command prompts the user. the valid options will
be listed in response to a . {The first of the listed options is
the default if end-of-file is encountered. such as from a command file.}
A valid response is any unique abbreviation of one of the listed options.
Standard UNIX documentation conventions are used in this report
to describe MH command syntax. Arguments enclosed in brackets
are optional; exactly one of the arguments enclosed within braces 0
must be specified. and all other arguments are required. The use of
ellipsis dots ( ... ) indicates zero or more repetitions of the previous
item. For example. u+folder ... would indicate that one or more
"+folder" arguments is required and ,,[ +folder ... ] .. indicates that 0 or
more u+folder" arguments may be given.
MH departs from UNIX standards by using switches that consist of
more than one character, e.g. "-header". To minimize typing. only a
unique abbreviation of a switch need be typed; thus. for "-header".
"-hea" is probably sufficient. depending on the other switches the
command accepts. Each MH program accepts the switch "-help"
(which must be spelled out fully) and produces a syntax description
and a list of switches. In the list of switches. parentheses indicate
reqpired characters. For example. all "-help" switches will appear as
"-(help)lI. indicating that no abbreviation is accepted.

n ])
n

It

-15Many MH switches have bothon and off formsi such as II-format"
and "-noformat". In many of the descriptions in Sec. V, only one form
is defined; the other form. often used to nullify protile switch settings,
is assumed to be the opposite.

-14JlH CODANDS
The'MH package comprises 16 programs:
comp
Comp~se a message
dist
Redistribute a message
file
Move messages between folders
folder
Select/list status of folders
forw
Forward a message
inc
Incorporate new mail
next
Show the next message
pick
Select a set of messages by context
prev
Show the previous message
prompter
Prompting editor front end for composing messages
repl
Reply to a message
rmf
Remove a folder
rmm
Remove messages
scan
Produce a scan listing of selected messages
send
Send a previously composed message
show
Show. messages
These programs are described below. The form of the descriptions
conforms to the standard form for the description of UNIX commands.

COMP(l)

-15-

COMP(l)

HAIlE

comp - compose a message
snrOPSIS

comp [ -editor editor] [-form formfile] [file ] [-use] [-nouse ] [-help]
DESCRIPTION

Olmp is used to ~reate a new message to be mailed. If file is not specified, the
file named "draft" in the user's MH directory will be used. Camp copies a message form to the file being composed and then invokes an editor on the file. The
default editor is /bin/ned, which may be overridden with the '-editor' switch or
with a profile entry "Editor:". (See Ref. 5 for a description of the NED text editing system.) The default message form contains the following elements:
To:
cc:
Subject:
If the file named "components" exists in the user's MH directory, it will be used
instead of this form. If '-form formfile' is specified, the specified formfile {from
the MH directory} will be used as the skeleton. The line of dashes or a blank line
must be left between the header and the body of the message for the message to
be identified properly when it is sent (see send;). The switch '-use' directs camp
to continue editing an already started message. That is, if a camp (or dist, repl,
or /arw) is terminated without sending the message, the message can be edited
again via "comp -use".
If the specified file (or draft) already exists, camp will ask if you want to delete it
before continuing. A reply of No will abort the camp. yes will replace the existing draft with a blank skeleton, list will display the draft, and use will use it for
further composition.
Upon exiting from the editor, camp will ask "What now?". The valid responses
are list. to list the draft on the terminal; quit, to terminate the session and
preserve the draft; quit delete, to terminate, then delete the draft; send. to
send the message; send verbose, to cause the delivery process to be monitored;
edit . to invoke  for further editing; and edit, to re-edit using
the same editor that was used on the preceding round unless a profile entry
"-nexl: " names an alterna~ive editor.

/etc/mh/components
or  /components
SHOME/. mh.profile
 / draft
/usr /bin/send

'lth Edition

The message skeleton
Rather than the standard skeleton
The user profile
The default IIl:essage tile
To send the composed message

UNIXl32V(Rand)

-16-

COIIP(l)

COMP(l)

ProfIle Components

Path:
Editor:
-next:

To determine the user's MH directory
To override the use of /bin/ned as the default editor
To name an editor to be used after exit from 

Defaults

lrue' defaults to draft
I-editor' defaults to /bin/ned
I-nouse'
Contest.

Camp does not affect either the current folder or the current message.

7th Edition

UN1XI32V(Rand)

DIST(l)

-17-

DIST(l)

NAIIE

dist - redistribute a message to additional addresses
SYNOPSIS

dist [+folder] [msg] [-form formfile] [-editor editor] [-annotate]
[-noannotate] [-inplace] [ -noinplace] [-help]
DESCRIPTION

is similar to lorw. It prepares the specified message for redistribution to
addresses that {presumably} are not on the original address list. The file
"distcomps" in the user's MH directory, or a standard form, or the file specified
by I-form for mfile , will be used as the blank components file to be prepended to
the message being distributed. The standard form has the components
"Distribute-to:" and "Distribute-cc:". When the message is sent, "Distribution- ...
Date: date", "Distribution-From: narne", and "Distribution-ld: id" (if '-msgid'
is specified to send;) will be prepended to the outgoing message. Only those
addresses in Distribute-To" • "Distribute-cc". and "Distribute-Bcc" will be sent.
Also, a "Distribute-Fcc: folder" will be honored (see send;).
[Jist

II

Send. recognizes a message as a redistribution message by the existence of the
field "Distribute-To:", so don't try to redistribute a message with only a
I'Distribute-cc:" .
If the I-annotate' switch is given, each message being distributed will be annotated with the lines:
Distributed: «date»
Distributed: Distribute-to: names
where each lito" list contains as many lines as required. This annotation will be
done only if the message is sent directly from dist. If the message is not sent
immediately from dist (Le., if it is sent later via send;), "comp -use" may be
used to re-edit and send the constructed message, but the annotations won't
take place. The '-inplace' switch causes annotation to be done in place in order
to preserve links to the annotated messag e.
See com:p for a description of the '-editor' switch and for options upon exiting
from the editor.

/etc/mh/components
or  / components
SHOME/. mh.protlie
I draft
lusr /bini send

The message skeleton
Rather than the standard skeleton
The user profile
The default message file
To send the composed message

P.rafile Components

Path:
Editor:
-nexl:

'lthEdition

To determine the user's MH directory
To override the use of Ibin/ned as the default editor
To name an editor to be used after exit from 

UN1XI32V(Rand)

DIST(l)

-18-

DIST(l)

Defaults

'+folder' defaults to the current folder
'msg' defaults to cur
'-editor' defaults to /bin/ned
'-noannotate'
'-noinplace'
Context

If a +folder is specified, it will become the current folder, and the current message will be set to the message being redistributed.

7th Edition

UN1X132V{Rand)

-19-

FJLE(l)

Ji1LE(1)

HAIlE

me - file message(s) in (an}other fOlder{s)
SYNOPSIS

tile [-src +folder] [msgs] [-link] [-preserve] +folder ... [-nolink]
[-nopreserve] [-tile file] [ -notile] [-help]
DESCRIPTION

File moves (mv(I)} or links (In{I)) messages from a source folder into one or·
more destination folders. If you think of a message as a sheet of paper this
operation is not unlike tiling the sheet of paper (or copies) in tile cabinet folders.
When a message is tiled, it is linked into the destination folder(s) if possible, and
is copied otherwise. As long as the destination folders are all on the same file
system, multiple filing causes little storage overhead. This facility provides a
good way to cross-file or multiply-index messages. For example, if a message is
received from J ones about the ARPA Map Project, the command
t

file cur +jones +Map
would allow the message to be found in either of the two folders 'jones' or 'Map'.
The option '-file file' directs file to use the specified file as the source message
to be filed, rather than a message from a folder.
If a destination folder doesn't exist, file will ask if you want to create one. A
negative response will abort the file operation.
'-link' preserves the source folder copy of the message (i. e., it does a In(I)
rather than a mv(I», whereas, '-nolink' deletes the "filed" messages from the
source folder. Normally. when a message is filed, it is assigned the next highest
number available in each of the destination folders. Use of the '-preserve'
switch will override this message "renaming", but name conflicts may occur, so
use this switch cautiously. (See pick for more details on message numbering.)
If '-link' is not specified (or '-nolink' is specified), the filed messages will be
removed (unlink(lI» from the source folder.
Wes

SHOME/. mh.protile

The user profile

Prafile Components

Path:
Current-Folder:
Folder-Protect:

To determine the user's MH directory
To find the default current folder
To set mode when creating a new folder

Defaults

'-src +folder' defaults to the current folder
'msgs' defaults to cur
'-nolink'
,-nopreserve'
'-nofile'

7th Edition

UNDU32V(Rand)

Fru.:(l)

m.J:(1)
Contezt.

If '-src +folder' is given, it will become the current folder for future MHcommands. If neither '-link' nor •all' are specified, the current message in the
source folder will be set to the last message specified; otherwise, the current
message won't be changed.

7th Edition

UNIX/32V(Rand)

-21-

FOLDER(1)

FOLDER(1)

HAIlE

folder - set/list current folder/message
SYNOPSIS

folder [+folder] [ms~] [-all] [-fast] [-nofast] [-up] [-dOwn] [-header]
[ -noheader] L-total] [ -nototal] [-pack] [-nopack] [-help]
folders 
DESCRIPTION

Since the MH environment is the shell, it is easy to lose track of the current
folder from day to day. Folder will list the current folder, the number of messages in it. the range of the messages {low-high}. and the current message
within the folder, and will flag a selection list or extra files if they exist. An
example of the output is:
inbox+ has 16 messages ( 3- 22); cur= 5.
If a '+folder' and/or 'msg' are specitled. they will become the current folder
and/or message. An '-all' switch will produce a line for each folder in the user's
MH directory, sorted alphabetically. These folders are preceded by the readonly folders, which occur as . mh.profile "cur-" entries. For example,
Folder
/fsd/rs/m/tacc
/rnd/phyl/Mail/EP
ff
inbox+
mb
notes
ucom

# of message{s range
has
has
has
has
has
has
has

35 message{s
82 messag s
4 messag s
16 messag s
76 messag s
2 messag s
124 messag s

}; cur msg (other files)
1- 35); cur= 23.
1-108); cur= 82.
1- 4); .cur= 1.
3- 22}; cur= 5.
1- 76); cur= 70.
1- 2}; cur= 1.
1-124); cur= 6; (select).

TOTAL= 339 messages in

7 Folders.

The "+" after inbox indicates that it is the current folder. The "(select)" indicates that the folder ucom has a selection list produced by pick. If "others" had
appeared in parentheses at the right of a line, it would indicate that there are
files in the folder directory that don't belong under the MH file naming scheme.
The header is output if either an '-all' or a '-header' switch is specified; it is
suppressed by '-noheader'. Also, if !older is invoked by a name ending with "s"
(e.g., !olders), '-all' is assumed. A '-total' switch will produce only the summary line.
If '-fast' is given, only the folder name (or names in the case of '-all') will be
listed. (This is faster because the folders need not be read.)
The switches '-up' and '-down' change the folder to be the one above or below
the current folder. That is, "folder -down" will set the folder to
" /select" and if the current folder is a selection-list folder,
"folder -up" will set the current folder to the parent of the selection-list. (See
pick for details on selection-lists.)
I

?thEdition

UNIX/32V(Rand)

roWER(l)

FOLDER(l)

The '-pack' switch will compress the message names in a folder, removing holes
in message numbering.
IDes

SHOME/. mh.profile
/bin/Is

The .user profile
To fast-list the folders

P.roftle Components

Path:
Current-Folder:

To determine the user's MH directory
To find the default current folder

Defllllhs

'+folder' defaults to the current folder
'msg' defaults to none
'-nofast'
'-noheader'
'-nototal'
'-nopack'
Qaten

If '+folder' and/or 'msg' are given, they will become the current folder and/or
message.

7th Edition

1JNIXI32V(Rand)

FORW(l)

FORW(l)

KAME

forw - forward messages
SYNOPSIS

forw [ +folder] [msgs] [ -editor editor] [-form formflle] [-annotate]
[-noannotate] [-inplace] [-noinplace] [-help]
DESCRIPTION

Forw may be used to prepare a message containing other messages. It con-·
structs the new message from the components file or '-form formfile' (see
comp), with a body composed of the message(s) to be forwarded. An editor is
invoked as in comp, and after editing is complete, the user is prompted before
the message is sent.
H the '-annotate' switch is given, each message being forwarded will be annotated with the lines

Forwarded: «date»
Forwarded: To: names
Forwarded: cc:names
where each "To:" and "cc:" list contains as many lines as required. This annotation will be done only if the message is sent directly from /orw. If the message
is not sent immediately from Jorw. "camp -use" may be used in a later session
to re-edit and send the constructed message, but the annotations won't take
place. The '-inplace' switch permits annotating a message in place in order to
preserve its links.
See comp for a description of the '-editor' switch.
/etc/nrun/components
or  /components
SHOME/. mh.protile
 / draft
/usr /bin/send

The message skeleton
Rather than the standard skeleton
The user profile
The default message file
To send the composed message

Profile Components

Path:
Editor:
Current-Folder:
-next:

To determine the user's MH directory

1:0 override the use of /bin/ned as the default editor
To find the default current folder
To name an editor to be used after exit from 

Defaults

'+folder' defaults to the current folder
'msgs' defaults to cur
'-editor' defaults to /bin/ned
'-no annot ate ,
'-noinplace'
Contezt.

If a +folder is specified, it will become the current folder, and the current message will be set to the first message being forwarded.
'1th Edition

UNDU32V{Rand)

FORW(l)

FORW(l)
KAlIl

inc - incorporate new mail
SYNOPSIS

inc [ +folder] [-audit audit-file1[-help]

DESCRIPTION

Inc incorporates mail from the user's incoming mail drop (. mail) into an MH
folder. If '+folder' isn't specified, the folder named "inbox" in the user's MH
directory will be used. The new messages being incorporated are assigned
numbers starting with the next highest number in the folder. If the specified (or
default) folder doesn't exist, the user will be queried prior to its creation. As the
messages are processed, a scan listing of the new mail is produced.
If the user's profile contains a "Msg-Protect: nnn" entry, it will be used as the
protection on the newly created messages, otherwise the MH default of 664 will
be used. During all operations on messages, this initially assigned protection
will be preserved for each message, so chmod{I) may be used to set a protection
on an individual message, and its protection will be preserved thereafter.
If the switch '-audit audit-file' is specified (usually as a default switch in the
profile), then inc will append a header line and a line per message to the end of
the specified audit-file with the format:
«inc» date



This is useful for keeping track of volume and source of incoming mail. Eventually, repl,/o'MJJ, camp. and d.ist may also produce audits to this (or another) file,
perhaps with "Message-Id:" information to keep an exact correspondence history. "Audit-file" will be in the user's MH directory unless a full path is
specified.

Inc will incorporate even illegally formatted messages into the user's MH folder,
inserting a blank line prior to the offending component and printing a comment
identifying the bad message.
In all cases, the . mail file will be zeroed.

SHOME/. mh.profile
SHOME/. mail
I audit-file
P.ram.e Compcments
Path:
Folder-Protect:
Msg-Protect:

The user profile
The user's mail drop
Audit trace file (optional)
To determine the user's MH directory
For protection on new folders
For protection on new messages

JWaults

'+folder' defaults to "inbox"

7th Edition

UNIXl32V(Rand)

INC(t)

INC(l)
Canten

The folder into which the message is being incorporated will become the current
folder and the tirst message incorporated will be the current message. This
leaves the context ready for a show of the first new message.
I

7th Edition

UNIXl32V(Rand)

-26-

NEXf(l)

HAIlE

next - show the next message
SYNOPSIS

next [+folder] [-switches for l]-[ -help]
DESCRIPTION

Next performs a show on the next message in the specified (or current) folder.
Like show, it passes any switches on to the program l, which is called to list the
message. This command is exactly equivalent to "show next".

SHOME/. mh.protile

The user profile

Profile Components

Path:
Current-Folder:

To determine the user's MH directory
To find the default current folder

Defaults
Context.

If a folder is specified. it will become the current folder, and the message that is
shown (Le., the next message in sequence) will become the current message.

?th Edition

UN1XI32V(Rand)

PICK(l)

-¥:'/-

PICK(l)

pick - select messages by content
SYNOPSIS

pick

-cc
-date
-from
-search
-subject
-to
--component

[-src +folder] [msgs] [-help] [-scan] [-noscan]
[-show] [-noshow] [-nofile] [ -nokeep ]
pattern
[-file [-preserve] [-link] +folder .... [-nopreserve] [-no1i~
[-keep [-stay] [-nostay] [ +folder ...J ]

typically:
pick -from jones -scan
pick -to holloway
pick -subject ned -scan -keep
D~ION

Pick searches messages within a folder for the specified contents, then performs
several operations on the selected messages.
A modified grep{I) is used to perform the searching, so the full regular expression (see ed(I}) facility is available within 'pattern'. With '-search', pattern is
used directly, and with the others, the grep pattern constructed is:

•

"component:. pattern"
This means that the pattern specified for a '-search' will be found everywhere in
the message, including the header and the body, while the other search requests
are limited to the single specified component. The expressioll '--component
pattern' is a shorthand for specifying '-search "component:. pattern" '; it is
used to pick a component not in the set [cc date from subject to]. An example
is "pick --reply-to pooh -show".
Searching is performed on a per-line basis. Within the header of the message,
each component is treated as one long line, but in the body, each line is
separate. Lower-case letters in the search pattern will match either lower or
upper case in the message, while upper case will match only upper case.
Once the search has been performed. the selected messages are scanned (see
sca.n) if the '-scan' switch is given. and then they are shown (see show) if the
'-show' switch is given. After these two operations, the tile operations (if
requested) are performed.
. The I-file' switch operates exactly like theftle command, with the same meaning
for the '-preserve' and '-link' switches.
The '-keep' switch is similar to '-tile., but it produces a folder that is a subfolder of t.he folder being searched and defines it as the current folder (unless
the '-stay' flag is used). This subfolder contains the messages which matched
the search criteria. All of the MH commands may be used with the sub-folder as
the current folder. This gives the user considerable power in dealing with subsets of messages in a folder.

7th Edition

UNlXI32V(Rand)

-28-

PICK(l)

PICK(l)

The messages in a folder produced by '-keep' will always have the same
numbers as they have in the source folder (Le., the '-preserve' switch is
automatic). This way, the message numbers are consistent with the folder from
which the messages were selected. Messaies are not removed from the source
~older (i.e .• the '-link' switch 'is assumed). If a '+folder' is not specified. the
standard name "select" will be used. (This is the meaning of "(select)'· when it
a.ppears in the output of the folder command.) If '+folder' arguments are given
to '-keep', they will be used rather than "select.. for the names of the subfolders. This allows for several subfolders to be maintained concurrently ..
When a '-keep' is performed. the subfolder becomes the current folder. This
can be overridden by use of the '-stay' switch.
Here's an example:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

% folder +inbox
inbox+ has 16 messages ( 3- 22): cur= 3.
% pick -from dcrocker
6 hits.
[+inbox/select now current]
% folder
inbox/select+ has 6 messages ( 3- 16); cur= 3.
% scan
3+ 6/20 Dcrocker
Re: ned tile update issue .. .
6 6/23 Dcrocker
removal of files from Itm .. .
8 6/27 Dcrocker
Problems with the new ned .. .
13 6/28 dcrocker
newest nned «I would ap .. .
15 7/ 5 Dcrocker
nned «Last week I asked .. .
16 7/ 5 dcrocker
message id format «I re .. .
% show alII print
[produce a· full listing of this set of messages on the line printer.]
% folder -up
inbox+ has 16 messages ( 3- 22); cur= 3; (select).
% folder -doWn
inbox/select+ has 6 messages ( 3- 16); cur= 3.
% rmf
[+inbox now current]
% folder
inbox+ has 16 messages ( 3- 22); cur= 3.

This is a rather lengthy example. but it shows the power of the MH package. In
item 1. the current folder is set to inbox. In 3, all of the messa~es from
dcrocker are found in inbox and linked into the folder "inbox/select". {Since no
action switch is specified, '-keep' is assumed.) Items 6 and 7 show that this subfolder is now the current folder. Items B through 14 are a sca.n of the selected
messages {note that they are all from dcrocker and are all in upper and lower
case}. Item 15 lists all of the messages to the high-speed printer. Item 17
directs folder to set the current folder to the parent of the selection-list folder,
which is now current. Item 18 shows that this has been done. Item 19 resets the
current folder to the selection list, and 21 removes the selection-list folder and
resets the current folder to the parent folder. as shown in 22 and 23.

mes
SHOME/. mb..protlle

7th Edition

The user profile
UN1X132Y(Rand)

PlCK(l)

-29-

PICK(l)

Pro1l1e Components

Path:
Folder-Protecl:
Current-Folder:

To determine the user's MH directory
For prolection on new folders
To find the default current folder

Defaults

'-src +folder' defaults to current
'msgs' defaulls to all
I-keep +selecl' is lhe default if no '-scan', '-show', or '-fUe' is specified
Conten

If a '-src +folder' is specified, il will become the current folder, unless a '-keep'
with 0 or 1 folder arguments makes the selection-list subfolder the current folder. Each selection-list folder will have its current message set to the first of the
messages linked into it unless the selection list already existed, in which case
the current message won't be changed.

7th Edition

UN1XI32V(Rand)

PREV(l)

PREV(l)
NAME

prev - show the previous message
SYHOPSIS

prev [+folder] [-switches for l] [-help]
DESCRIPTION

?rev performs a show on the previous message in the specified (or current)
folder. Like show, it passes any switches on to the program l, which is called to
list the message. This command is exactly equivalent to "show prev".

SHOME/. mh.profile

The user profile

P.ra6le Compcments

Path:
Current-Folder:

To determine the user's MH directory
To find the default current folder

Defaults

Context.

If a folder is specified, it will become current, and the message that is shown
(i.e., the previous message in sequence) will become the current message.

7th Edition

UN1X132V(Rand)

-31IfAIlE

prompter - prompting editor front end
SYNOPSIS

This program is not called directly but takes the place of an editor and acts as
an editor front end.
prompter [-erase chr] [-kill chr] [-help]
DESCRIPTION

Prompter is an editor which allows rapid composition of messages. It is particu- .
larly useful to network and low-speed (less than 2400 baud) users of MH. It is an
MH program in that it can have its own profile entry with switches. but it can't
be invoked directly as all other MH commands can; it is an editor in that it is
invoked by an .. -editor prompter" switch or by the profile entry "Editor:
prompter", but functionally it is merely a text-collector and not a true editor.
Prompter expects to be called from comp, repl, dist. or /orw, with a draft file as
an argument. For example. "camp -editor prompter" will call prompter with
the file .. draft" already set up with blank components. For each blank component it finds in the draft. it prompts the user and accepts a response. A
 will cause the whole component to be left out. A .. ,,. preceding a
 will continue the response on the next line, allowing for multiline
components.
Any component that is non-blank will be copied and echoed to the terminal.
The start of the message body is prompted by a line of dashes. If the body is
non-blank, the prompt is "-------Enter additional text". Message-body typing is
terminated with a  (or  during message-body typing is equivalent to  for compatibility with NED. A  during component typing will abort the command that
invoked prompter.
None
PM61e Components

prompter-next:

To name the editor to be used on exit from prompter

Defaults

Cantezt.

None

7th Edition

UNlXJ32V(Rand)

REPL(l)

-62-

REPL(1)

HAIlE

repl - reply to a messag e
SYlfOPSIS

,repl [+folder] [ms~J [-editor editor] [-inplace] [-annotate] [-help]
[-noinplace J [-noannotate]
DESCRIPTION

Rep! aids a user in producing a reply to an existing message. In its simplest
form (with no arguments), it will set up a message-form skeleton in reply to the
current message in the current folder, invoke the editor, and send the composed message if so directed. The composed message is constructed as follows:

To:  or 
cc: . 
Subject: Re: 
In-reply-to: Your message of 

where field names enclosed in angle brackets « » indicate the contents of the
named field from the message to which the reply is being made. Once the skeleton is constructed, an editor is invoked (as in comp, dist, and fO'TW). While in the
editor, the message being replied to is available through a link named "@". In
NED. this means the replied-to message may be "used" with "use @", or put in a
window by "window @" .

As in comp, dist, and fO'TW, the user will be queried before the message is sent.
If I-annotate' is specified, the replied-to message will be annotated with the single line
Replied: «Date».
The command" comp -use" may be used to pick up interrupted editing, as in
d.ist and !O'TW; the '-inplace' switch annotates the message in place, so that all
folders with links to it will see the annotation.
SHOME/. mh.profile
 / draft
/usr /bin/send

The user profile
The constructed message file
To send the composed message

Profile Components

Path:
Editor:
Current-Folder:

To determine the user's MH directory
To override the use of /bin/ned as the default editor
To find the default current folder

Defaults

•+folder" defaults to current
'msgs' defaults to cur
'-editor' defaults to /bin/ned
'-noannotate'
'-noinplace'

'lth Edition

UNIXl32V(Rand)

REPL(l)

-33-

REPL(1)

Ccmtezt.

If a '+folder' is specified, it will become the current folder. and the current message will be set to the replied-to message.

7th Edition

UNIX/32V(Rand)

RllF(l)

RllF(l)
NAIIE

rmf - remove folder
SYNOPSIS

rmf [ +folder] [-help]
DRSCRIPTIOM

Rm/ ~emoves all of the files (messages) within the specified (or default) folder.
and then removes the directory {folder}. If there are any files within the folder
which are not a part of MH. they will not be removed. and an error will be produced. If the folder is given explicitly or the current folder is a subfolder {Le .• a
selection list from pick}. it will be removed without confirmation. If no argument is specified and the current folder is not a selection-list folder. the user
will be asked for confirmation.

Rrn/ irreversibly deletes messages that don't have other links. so use it with
caution.
If the folder being removed is a subfolder. the parent folder will become the new
current folder, and rrnJ will produce a message telling the user this has happened. This provides an easy mechanism for selecting a set of messages.
operating on the list. then removin~ the list and returning to the current folder
from which the list was extracted. (See the example under pick.)
The files that rm/ will delete are cur. any file beginning with a comma, and files
with purely numeric names. All others will produce error messages.

Rrn/ of a read-only folder

will delete the "cur-" entry from the profile without

affecting the folder itself.
lUes

SHOME/. mh~rofile

The user profile

Profile Components

Path:
Current-Folder:

To determine the user's MH directory
To find the default current folder

Defaults

I+folder' defaults to current. usually with confirmation
Context.

Rrn/ will set the current folder to the parent folder if a subfolder is removed; or
if the current folder is removed, it will make "inbox" current. Otherwise. it

doesn't change the current folder or message.

7th Edition

UNlX/32V(Rand)

01(1)

.-35-

RMJl(l)

rmm. - remove messages
rNOPSIS

rmm [+folder] [msgs] [-help]
gscrupnON

Rmm. removes the specitled messages by renaming the message tiles with
preceding commas. (This is the Rand-UNIX backup file convention.)
The current message is not changed by rmm.. so a nezt will advance to the next
message in the folder as expected.
Des

$HOME/. mh.profile

The user profile

lrofIle Components

Path:
Current-Folder:

To determine the user's MH directory
To find the default current folder

lefaults

'+folder' defaults to current
'msgs' defaults to cur
Canten

If a folder is given, it will become current.

7th Edition

UNIX/32V(Rand)

SCAN(1)

SCAN(l)

HAIlE

scan - produce a one-line-per-message scan listing
SYKOPSIS

scan [+folder] [msgs] [-ff] [-header] [-h~lp] [-noff] [-noheader]

DESCRIPTION

Scan produces a one-line-per-message listing of the specified messages. Each
scan line contains the message number (name), the date, the "From" field, the
"Subject" field, and, if room allows, some of the body of the message. For example:

II

15+
1618
19

Date

7/
7/
7/
7/

5
5
6
7

Subject [«Body]
nned «Last week 1 asked sonle of
message id format «1 recommend
Re: Exit status from mkdir
"scan" listing format in MH

From
Dcrocker
dcrocker
Obrien
Obrien

The '+' on message 15 indicates that it is the current message. The '-' on message 16 indicates that it has been replied to, as indicated by a "Replied:" component produced by an '-annotate' switch to the repl command.
If there is sufficient room left on the sca.n line after the subject, the line will be
tilled with text from the body, preceded by «. Scan actually reads each of the
specified messages and parses them to extract the desired fields. During parsing, appropriate error messages will be produced if there are formal errors in
any of the messages.
The I-header' switch produces a header line prior to the scan listing, and the
'-ff' switch will cause a form feed to be output at the end of the scan listing.
See Appendix D.
SHOME/. mh-profile

The user profile

P.raftle Components

Path:
Current-Folder:

To determine the user's MH directory
To find the default current folder

Defaults

Defaults:
'+folder' defaults to current
'msgs' defaults to all
I-noff
I-noheader'
CDltext.

If a folder is given. it will become current. The current message is unaffected.

'lth Edition

UNIX/32V(Rand)

SEND(l)

-87-

BEND(l)

MAIlE

send - send a message
SYNOPSIS

send [tile] [-draft] [-verboseJf-format] [-msgid] [-help] [-noverbose]
[-noformat] [-nomsgid
DESCRIPTION

Send. will cause the specified file (default /draft) to be delivered to
each of the addresses in the liTo:", "CC:", and "Bcc:" fields of the message. If
'-verbose' is specified, send; will monitor the delivery of local and net mail.
Send. with no argument will query whether the draft is the intended file, whereas
'-draft' will suppress this question. Once the message has been mailed (or
queued) successfully, the file will be renamed with a leading comma, which
allows it to be retreived until the next draft message is sent. If there are errors
in the formatting of the message. send.,· will abort with a (hopefully) helpful error
message.
If a "Bcc:" field is encountered. its addresses will be used for delivery, but the
"Bcc:" field itself will be deleted from all copies of the outgoing message.
Prior to sending the message, the fields "From: user", and "Date: now" will be
prepended to the message. If '-msgid' is specified, then a "Message-Id:" field
will also be added to the message. If the message already contains a "From:"
field. then a "Sender: user" field will be added instead. (An already existing
"Sender:" field will be deleted from the message.)
If the user doesn't specify '-noformat'. each of the entries in the "To:" and
"cc:" fields will be replaced with "standard" format entries. This standard format is designed to be usable by all of the message handlers on the various systems around the ARPANET.
If an "Fcc: folder" is encountered, the message will be copied to the specified
folder in the format in which it will appear to any receivers of the message. That
is, it will have the prepended fields and field reformatting.

If a "Distribute-To:" field is encountered, the message is handled as a redistribution message (see dist for details). with "Distribution-Date: now" and
"Distribution-From: user" added.
lUea

SHOME/. m.h..protlle

The user profile

P.ra61e Components

Path:

To determine the user's MH directory

Defaults

'file· defaults to draft
'-noverbose'
'-format'
'-nomsgid'
Caaten

Send. has no effect on the current message or folder.

7th Edition

UNIX/32V(Rand)

SEND(l)

SEND(!)
HAIlE

show - show {list} messages
BnlOPSIS

show [+folder] [msgs] [-pr] [-nopr] [-draft] [-help] [lor pre switches]
DKSCRIPTION

Show lists each of the specified messages to the standard output {typically, the
terminal}. The messages are listed exactly as they are, with no reformatting. A
program called 1 is i~voked to do the listing, and any switches not recognized by
show are passed along to t.
.
If no "msgs" are specified, the current message is used. If more than one message is specified, Z will prompt for a  prior to listing each message.
1 will list each message, a page at a time. When the end of page is reached, 1 will
ring the bell and wait for a  or . If a  is entered, 1
will clear the screen before listing tbe next page, whereas  will not.
The switches to 1 are '-pH' to indicate the page length in lines, and '-wH' to indicate the width of the page in characters.

If the standard output is not a terminal, no queries are made, and each file is
listed with a one-line header and two lines of separation.
If '-pr' is specified, then pr(I} will be invoked rather than 1,' and the switches
(other than '-draft') will be passed along. "Show -draft" will list the file  Idraft if it exists.

SHOME/. mh.protile
/binll
/bin/pr

The user profile
Screen-at-a-time list program
pr(I)

Profile Components

Path:
Current-Folder:

To determine the user's MH directory
To find the default current folder

Defaults

'+folder' defaults to current
'msgs' defaults to cur
'-nopr'
Ccmtezt.

If a folder is given, it will become tbe current message. The last message listed
will become the current message.

?thEdition

UNIXl32V(Rand)

Appendix A

COMMAND SlJMMA.Ry3

comp [-editor editor] [-form formfile] [file] [-use] [-nouse] [-help]
dist [+folder] [msg] [-form formfile] [-editor editor] [-annotate] [-noannotate]
[-inplace] [-noinplace] [ -help]
file [-src +folder] [msgs] [-link] [-preserve] +folder ... [-nolink] [-nopreserve]
[-flle file] [-nofile] [-help]
folder [+folder] [msg] [-all] [-fast] [-nofast] [-up] [-down] [-header] [-no header]
[-total] [-nototal] [-pack] [-nopack] .[-help]
forw [+folder] [msgs] [-editor editor] [-form formfile] [-annotate] [-noannotate]
[-inplace] [-noinplace] [-help]
inc [+folder] [-audit audit-file] [-help]
next [+folder]
pick

[~switches

-cc
-date
':"from
-search
-subject
-to
--component

for t] [-help]
[-src +folder] {tnsgs] [ -help] [-scan] [-noscan]
[ --show] [-noshow] [ -nofile] [-nokeep]
pattern
[-file [-preserve] [-link] +folder ... [-nopreserve] [-nolink] ]
[-keep [-stay] [-nostay] [+folder ... ]]

prev [+folder] [-switches for l] [-help]
prompter [-erase chr] [-kill chr] [-help]
repl [+folder] [msg] [-editor editor] [-inplace] [-annotate] [-help] [-noinplace]
[-noannotate]
rmf [ +folder] [-help]
rmm [+folder] [msgs] [-help]
scan [ +folder] [msgsI [-ff] [-headerl[-help] [-noff] [-noheader]
send [file] [-draft] [-verbose] [-format] [-msgid] [-help] [-noverbose] [-noformat]
[-nomsgid]
show [+folder] [msgs] [-prj [-nopr] [-draft] [-help] [lor pr switches]

'All commands accept a-help switch.

-89-

AppendixB·
M~AGE

FORMAT

This section paraphrases the format of ARPANET text messages
given in Ref. 6.
ASSUMPTIONS
(i) Messages are expected to consist of lines of text. Graphics and
binary data are not handled.
(2) No data compression is accepted. All text is clear ASCII 7-bit data.
LAYOUT
A general "memo" framework is used. A message consists of a block of
information in a rigid format, followed by general text with no specified
format. The rigidly formatted first part of a message is called the
. header, and the free-format portion is called the body. The header
must always exist, but the body is optional.

THE HEADER
Each header item can be viewed as a single logical line of ASCII cp,aracterse If the text of a header item extends across several real lines, the
continuation lines are indicated by leading spaces or tabs.
Each header item is called a component and is composed of a keyword
or name. along with associated text. The keyword begins at the left
margin. may contain spaces or tabs. may not exceed 63 characters,
and is terminated by a colon (:). Certain components (as identified by
their keywords) must follow rigidly defined formats in their text portions.
The text for most formatted components (e.g .• "Date:" and "MessageId:") is produced automatically. The only ones entered by the user are
address fields such as liTo:", "cc:", etc. ARPA addresses are assigned
mailbox names and host computer specifications. The rough format is
"mailbox at host". such as "Borden at Rand-Unix". Multiple addresses
are separated by commas. A missing host is assumed to be the local
host.
THE BODY
A blank line signals that all following text up to the end of the file is the
body. {A blank line is defined as a pair of  characters with
no characters in between.} No formatting is expected or enforced
within the body.
Within MH. a line consisting of dashes is accepted as the header delimiter. This is a cosmetic feature applying only to locally composed mail.

Appendix C

MESSAGE NAME BNF

msgs

..-

msgspec

.-

msg

.-

msg-name

.-

msgspec
msgs msgspec
msg
msg-range
msg-sequence
msg-name

"first"
last"
"cur"

II

....

"next"
"prev"
msg-range

.-

msg"-"msg
"all"

msg-sequence

.-

msg'

signed-number .-

I:"

signed-number

+" 
"--"


II

Where  is a decimal number in the range 1 to 999.
Msg-range specifies all of the messages in the given range and
must not be empty.
Msg-sequence specifies up to  of messages. beginning
with "msg" (in the case of first. cur. next. or  forces "starting
with msg". and - forces "ending with number". In all cases.
"msg" must exist.

-41-

Appendix D

EXAMPLE OF SHELL COMMANDS

UNIX commands may be mixed with MH comma.1)ds to obtain additional functions. These may be prepared as files (known as shell command tiles or shell scripts). The following example is a useful function
that illustrate the possibilities. Other functions, such as copying, deleting, renaming, etc., can be achieved in a ~imilar fashion.
HARDCOPY
The command:
(scan -ff -header; show all -pr -f)

I print

produces a scan listing of the current folder, followed by a form feed,
followed by a formatted listing of all messages in the folder, one per
page. Omitting "-pr -r' will cause the messages to be concatenated,
separated by a one-line header and two blank lines.
You can create variations on this theme, using pick.

REFERENCES

1. Crocker. D. H., J. J. Vittal. K. T. Pogran, and D. A. Henderson, Jr.,
"Standard for the Format of ARPA Network Test Messages,"
Arpanet Request for Comments. No. 733, Network Information
Center 41952, Augmentation Research Center, Stanford Research
Institute, November 1977.
2. Thompson, K., and D. M. Ritchie, "The UNIX Time-sharing System.
Communications of the ACM, Vol. 17. July 1974, pp. 365-375.

II

3. McCauley, E. J., and P. J. Drongowski, "KSOS-The Design of a Secure
Operating System," AFIPS Conference Proceedings, National Computer Conference, VoL 48, 1979, pp. 345-353.
4. Crocker, David H., Framework and FUnctions of th2 "MS" Personal
Message System. The Rand Corporation, R-2134-ARPA, December
1977.
5. Thompson, K., and D. M. Ritchie, UNIX Programmer's Manual, 6th
ed., Western Electric Company. May 1975 (available only to UNIX
licensee s).
6. Bilofsky, Walter, The CRT Text Editor NED-Introduction and Reference Manual. The Rand Corporation, R-2176-ARPA, December
1977.



Source Exif Data:
File Type                       : PDF
File Type Extension             : pdf
MIME Type                       : application/pdf
PDF Version                     : 1.3
Linearized                      : No
XMP Toolkit                     : Adobe XMP Core 4.2.1-c043 52.372728, 2009/01/18-15:56:37
Create Date                     : 2014:11:10 12:46:23-08:00
Modify Date                     : 2014:11:10 12:09:38-08:00
Metadata Date                   : 2014:11:10 12:09:38-08:00
Producer                        : Adobe Acrobat 9.55 Paper Capture Plug-in
Format                          : application/pdf
Document ID                     : uuid:650041c8-eaeb-204e-bd10-21feb0430409
Instance ID                     : uuid:e44ccb3d-9fa8-9a41-acdf-59e83520651a
Page Layout                     : SinglePage
Page Mode                       : UseNone
Page Count                      : 80
EXIF Metadata provided by EXIF.tools

Navigation menu