4.2_BSD_User_Contributed_Software 4.2 BSD User Contributed Software

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.

Authors:

AEL

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 dis-

tribution

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

func-

tions

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

V

AXes.

(Workspaces'

are

not

directly

interchangeable

but

can

be

converted).

Authors:

Address:

Timothy

A.

Budd

Gary

M.

Levin

Bib

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

format-

ted

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

-2-

selected

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)

ucb~cooper

(tnJCP)

This

is

the

Courier

remote

procedure

call

protocol

for

Berkeley

UNIX

(ver-

sion 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

rem-

iniscent

of Mesa.

provides

a

simple

way

of

defining

the

remote

interfaces

of

dis-

tributed

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

pro-

vides 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

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 well-

suited

for

nonnumerical

applications.

Icon

supports

several

data

types.

includ-

ing

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:

I

decvax.

vax135.

allegra.harpo

•... J!cornell!pavel

Pavel.

Cornell@Udel-Relay

August

11. 1983

Authors:

Help

from:

-4-

I 1lH

maiJ

~t

..

m

Bruce

Borden

Stockton

Gaines

Norman

Shapiro

Phyllis

Kantar

Robert

Anderson

David

Crocker

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

pro-

gram

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.

copy-

ing.

deleting.

cat.aloging. off-line print.ing.

etc..

are

applicable

to

messages

and

directories

of

messages

(folders). Thus, important.

capabilities

needed

in

a

mes-

sage

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

sys-

tem.

It

also· allows

users

familiar

with

the

shell

t.o

use

MH

wit.h

minimal

etTort.

Aut.hors:

Nntesfiles

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

dis-

cussion

of

personal

'Workstations, a

ditferent

group

may

desire

detailed

discus-

sions

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

-5-

Each

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

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 revi-

sions.

RCS

is useful

for

text

that

is

revised

frequently,

for

example

programs,

documentation.

graphics,

papers,

form

letters,

etc.

Author:

Kenneth

L.

Greer

2065 Alma St.

Sccstorcs

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

sees.

but.

instead

provides

a

way

of

coordinating

these

tools.

.

SPMS

can

be

titted

to

existing

software

systems.

It

retains

the

full

capabili-

ties

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.

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

arti-

cle

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

pro-

cessing

strings

and

lists.

leon

has

several

novel

features,

including

expressions

that

may

produce

sequences

of

results,

goal-directed

evaluation

that

automati-

cally

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

pro-

grams.

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

SNO-

BOlA,

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

UNIX

t

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

of

characters

may

be

arbitrarily

long.

limited

only

by

the

architec-

ture

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

can-

not

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

-3-

flnd(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

char-

acters

that

occur

in

s.

An

example

of

the

use

of

many

is

in

locating

words.

Sup-

pose,

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

pro-

duces

the

from

the

input

file,

but

fails

when

the

end

of

the

file

is

reached.

The following

expression

is

typical

of

programming

in

Icon

and

illus-

trates

the

integration

of

conditional

expressions

and

conventional

control

struc-

tures:

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

previ-

ous

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

gen-

erator

is

resumed

and

produces

the

second

position,

23,

which

is

greater

than

5.

-5-

The

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

sen-

tence2.

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

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

sen-

tence2.

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

opera-

tions,

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

per-

forms

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

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

new

posi-

tions.

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.

writ-

ing

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

pro-

duces

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

scan-

ning

expression.

Unlike

SNOBOL4.

in

which

the

operations

that

are

allowed

in

pat-

tern

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,

fails.

write(carl[5])

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

con-

structed

in

this

way.

For

example.

nodel

:=

["a"]

node2

:=

[nodel.

"b"]

push(node

1,

node2)

-6-

constructs

a

structure

that

can

be

pictured

as

follows:

nodel

.

->a--.

I I

node2 '--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

associ-

ative

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

two-

element

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

exam-

ple

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.

-9-

The

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

pro-

duce

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

end

line?

while

tab(upto(letters»

do

t

word

:=

tab(many(letters»

suspend

word

J

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

list

:#

get

arc

list

:#

sorted

nodes

:#

nodes

without

predecessoli

while *(roots

:=

nodes

--

snodes(arcs»

> 0

do

t

sorted

II:

=

roots

:#

add

to

sorted

nodes

--:=

roots

:#

delete

these

nodes

arcs

:=

delarcs(arcs.

roots)

:#

delete

their

arcs

J

if

*arcs

= 0

then

write(sorted)

else

write("

graph

has

cycle") #

successfully

sorted

:#

cycle

if

node

remains

J

end

-10-

procedure

snodes(arcs)

local

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

is

given

as

---------------.

I

I t

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

tit

I I I

I t I

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

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

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

1. Griswold,

Ralph

E.,

Poage,

James

F.,

and

Polonsky,

Ivan

P.

The

SNOBOL4 Pro-

gra.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.

Release

5g

of

Icon

Release

5g

orlcon

is

an

implementation

of

Icon

that

runs

on

both

PDP-11 s

and

V

AXs

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

PDP-

11.

• The

&output

and

&errout

output

streams

are

now line

buffered

by

default.

This

pro-

vides

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.

A

number

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

execu-

tion.

This

may

occur

during

type

conversion.

• Line

numbers

may

be

wrong

in

diagnostic

messages

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

es-

sagesmayoccurduringlinking.

• 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

SY5-

temaninordinatelylongtimetodeterminethattheobjectcannotbeallocated.

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

dis-

tribution

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.

Dur-

ing

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 kilo-

bytes

of

disk

space.

These

figures

vary

slightly

depending

upon

the

logical

organiza-

tion

of

a

particular

disk.

2.

InstallationProcedure

2.1.

Unloading

the

Distribution

Tape

The

system

is

distributed

as

a

tar

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

fol-

lowing

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 V

AX.

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

Iwrr

licon/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]

l

-ibinlibra.ry

directory/or

the

/coninte7pTeter]

-cbinlibra.rydirectory/orthe

iconcompiler]

-iconxlocationo/the

Iconinterpreter]

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,

Sys-

tem

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

directlyexecut-

able.

--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

direc-

tories

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.

Ifalter-

nate

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

inter-

preter

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

con-

tains

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

exe-

cutable.

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

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

argu-

ment.

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,

other-

wise,

the

latter

method

will

be

used.

The

first

method

is

preferable

in

that

the

inter-

pretable

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

sys-

tem

using

icon-setup,

specify

the

new

location

oficonxusing

the

-iconxoption.

For

example:

-icon~tup

other

arguments

-iconx:

lusr

Ilocal/iconx

Be

sure

to

place

a

copy

of

iconx

in

the

specified

location

after

the

system

is

com-

pletelybuilt.

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

pro-

grams

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.

-5-

4.

Assortedlnformation

The

following

sections

contain

information

that

is

not

neede

d

during

the

installa-

tion

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.

h

Headerfllesthatareincludedinothersourcefiles.

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

bin

Source

code

forthe

Icon

interpreter

proper.

Libraries

and

executable

versions

of

various

system

components.

The

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.

Occa-

sionally,

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

pos-

sible.

Because

the

same

source

is

used

to

produce

versions

of

Icon

on

both

V

AXs

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.

-6-

4.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

pro-

cessed

by

the

Icon

compiler

arelinked

together

with

a

library

(

cmp/bin/libLa)

of

the

runtime

system

subroutines.

When

changes

are

made

to

the

interpreterruntimesys-

tern.

all

aftected

libraries

must

be

rebuilt

and

then

iconxmust

be

rebuilt.

For

exam-

pIe.

if

the

files

int/operators/bang.c

and

int/functions/read

c

have

beenmodi

fled.

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

com-

mands

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

Icon

Translator

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.

#

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!

-7-

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

M

ail

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

sugges-

tionsaboutIconingeneralortheinstallationprocessinparticular.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

1-

4.

RaiphE.

Griswoidand

WilliamH. Mitchell. E:cperimentalEzter..sior..sto Icon.

Depart-

ment

of

Computer

Science.

The

University

of

Arizona.

March

1983.

-8-

RalphE.

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

avail-

able

at

some

point

in

the

future.

One

important

difference

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

declara-

tion

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

upward-

compatible

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.

Invocation

Via

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

pro-

cedure

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

PREFACE

........................................ u

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

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

i

SUMMARY

...............................................•....................................... v

Section

1.

INTRODUCTION

......................................................•................. 2

2.

OVERVIEW

................. .................. .............•.............................. 4

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

..

........ .............. ....... ..... ...

..

... ...... 6

4.

DETAILED

DESCRIPTION

.................. .................................. ...... 9

mE

USER

PROFILE

.•.................................. ............... ........... 9

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

OTHER

MH

CONVENTIONS

........ ....... ........ ............................. 12

MH

COMMANDS

................................ ..................................... 14

COMP

.............................................................................

15

DIST

.....................................

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

17

FIlE

...............................................................................

19

FOLDER

. ......................................................................... 21

FORW

............................................................................. 23

INC

................................................................... .............

24

NEX'r

............................................................................. 26

PICK ...... ..... ..... ........ ...... ... ................ ............ ................. 27

PREY ......••.......••.. .... .••.. ........•..•.•.....•....... ..... ..••.....•....•.. 30

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

..

...... . .

..

. 31

REPL .............................................................................. 32

RMF

.....................................................

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

34

RMM

...............................................................................

35

SCAN

............................................................................. 36

SEND ....................... ...•••.••..•.•••.••••.•••..•.... ...••..••... ....... ... 37

SHOW....................... ...................... ....................... ......... 38

Appendix

A.

Command

Summary

.................................... .... ................... .. .

39

B.

Message

Format

....... ................ ........ ..................... .................. 40

C.

Message

Name

BNF

...•...•.....•............•......•.. ........•................... 41

D.

Example

of

Shell

Com.rnands ........................ ..........................

42

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

43

PREFACE

This

report

describes

a

system

for

dealing

with

me

ssag

es

transmit-

ted

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

computer-

based

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

time-

sharing

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

sys-

tems,

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

imple-

mentation.

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

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".

directory

system

of

UNIX

are

used

directly.

Mes-

sages

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

com-

mands

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

facili-

ties

can

be

applied

directly

to

individual

messages.

MH,

therefore.

con-

sists

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.

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

message-

handling

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

fold-

ers.

Using

the

UNIX

"link"

facility,

~t

is

possible

for

one

copy

of a

mes-

sage

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

avail-

able

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

con-

tains

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

(incor-

porate)

adds

the

new

messages

to

a

folder

called

'"inbox",

assigning

them

names

which

are

consecutive

integers

starting

with

the

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,

the

message

preceding

the

current

message,

and

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

mes-

sages

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

mes-

sages;

and

repl

facilitates

the

generation

of

a

reply

to

an

incoming

mes-

sage.

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:

7+

7/13

Cas

8

10/

9

Norm

revival

of

measurement

work

9

11/26

To:norm

NBS

people

and

publications

question

«Are

there

any

functions

This

shows

the

messages

you

received

since

the

last

time

you

exe-

cuted

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.

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:"

com-

ponent

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

com-

mand.

For

example,

show

5 will

show

message

5.

-7-

You

can

use

the

show

command

to

copy

a

message

or

print

a

mes-

sage.

shaw

> %

will

copy

the

message

to

file x.

show

I

print

will

print

the

message,

using

the

print

command.

show

the

message

that

follows

the

current

message.

prell will

show

the

message

the

current

message.

rmm

will

remove

the

current

message.

rmm

3 will

remove

message

3.

camp

The

camp

command

puts

you

in

the

editor

to

write

or

edit

a

mes-

sage.

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/<name>/Mail/draft

(where

/usr/<name>

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

mes-

sage.

Backspacing

is

the

only

form

of

editing

allowed

with

this

editor.

When

the

body

is

complete.

type

a

carriage

return

followed

by

<CTRL-

D>

«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

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

men-

tioned,

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

sys-

tem

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

mes-

sages

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

com-

ponents

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

informa-

tion

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

pro-

tections,

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

"Folder-

Protect",

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

set-

ting

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]

-10-

the

profile.

In

UNIX,

a

program

may

exist

under

several

names,

either

by

link-

ing

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:

II.

The

argument

to

"Editor~'

is

the

name

of

an

execut-

able

program

or

shell

command

file

which

can

be

found

via

the

user's

SPATH

defined

search

path,

excluding

the

cur.·ant

directory.

The

"Edi-

tor:"

profile

specification

may

in

turn

be

overridden

by

a

"-editor

<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

com-

posed

(see

the

discussion

of camp

in

Section

5 for detailS). A

profile

entry

II

<lasteditor>-next:

<editor>"

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

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

mes-

sage

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,

typi-

cal

arguments,

and

the

programs

that

reference

the

entries.

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.

-11-

Folder-Protect.:

711 file, inc,

pick·

<program>:

default

switches

All

cur-<read-onlyfolder>:

172

Most

prompter-next:

ed

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

the

current

message;

"next"

is

the

message

numerically

following

the

current

mes-

sage;

"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

last:5

-12-

The

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.

How-

ever.

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.

II

+inbox"

is

the

name

of

the

user's

stan-

dard

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".

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 <RETURN>. {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

n

])

are

optional;

exactly

one

of

the

arguments

enclosed

within

braces

0 n

must

be

specified.

and

all

other

arguments

are

required.

The

use

of

ellipsis

dots

( ... )

indicates

zero

or

more

repetitions

of

the

For

example.

u+folder

...

It

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.

-15-

Many

MH

switches

have

bothon

and

off

formsi

such

as

II-format"

and

"-

no

format".

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.

-14-

JlH

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

the

pick

Select

a

set

of

messages

by

context

the

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

mes-

sage

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

edit-

ing

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

exist-

ing

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

<editor>.

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

"<lasteditor>-nexl:

<editor>"

names

an

alterna~ive

editor.

/etc/mh/components

or

<mh-d.ir>

/components

SHOME/.

mh.profile

<mh-dir>

/

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)

COIIP(l)

ProfIle

Components

Path:

-16- COMP(l)

Editor:

<lasteditor>-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

<lastedi-

tor>

Defaults

Contest.

lrue'

defaults

to

draft

I-editor'

defaults

to

/bin/ned

I-nouse'

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

[Jist

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

II

Distribute-To"

•

"Distribute-cc".

and

"Distribute-Bcc"

will

be

sent.

Also, a

"Distribute-Fcc:

folder"

will

be

honored

(see

send;).

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

anno-

tated

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

<mh-dir>

/

components

SHOME/.

mh.protlie

<m.h-dir> I

draft

lusr /bini

send

P.rafile Components

Path:

Editor:

<lasteditor>-nexl:

'lthEdition

The

message

skeleton

Rather

than

the

standard

skeleton

The

user

profile

The

default

message

file

To

send

the

composed

message

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

<lastedi-

tor>

UN1XI32V(Rand)

DIST(l) -18-

Defaults

'+folder'

defaults

to

the

current

folder

'msg'

defaults

to

cur

'-editor'

defaults

to

/bin/ned

'-noannotate'

'-noinplace'

Context

DIST(l)

If

a

+folder

is

specified,

it

will

become

the

current

folder,

and

the

current

mes-

sage

will

be

set

to

the

message

being

redistributed.

7th

Edition

UN1X132V{Rand)

FJLE(l) -19-

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

Wes

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

t

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

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

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.

SHOME/.

mh.protile

The

user

profile

Prafile

Components

Path:

To

determine

the

user's

MH

directory

To

find

the

default

current

folder

Current-Folder:

Folder-Protect:

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)

m.J:(1)

Fru.:(l)

Contezt. If

'-src

+folder'

is

given,

it

will

become

the

current

folder

for

future

MHcom-

mands.

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)

FOLDER(1)

-21- 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

<equivalent

to

'folder

-all'

>

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

mes-

sages

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

read-

only

folders,

which

occur

as

.

mh.profile

"cur-"

entries.

For

example,

Folder

#

of

message{s

range

};

cur

msg

(other

files)

/fsd/rs/m/tacc

has

35

message{s

1-

35);

cur=

23.

/rnd/phyl/Mail/EP

has

82

messag

s

1-108);

cur=

82.

ff

has

4

messag

s

1-

4);

.cur=

1.

inbox+

has

16

messag

s

3-

22};

cur=

5.

mb

has

76

messag

s

1-

76);

cur=

70.

notes

has

2

messag

s

1-

2};

cur=

1.

ucom

has

124

messag

s

1-124);

cur=

6;

(select).

TOTAL=

339

messages

in

7

Folders.

The

"+"

after

inbox

indicates

that

it

is

the

current

folder.

The

"(select)"

indi-

cates

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

sum-

mary

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

"<current-folder>

/select"

I

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.)

?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

P.roftle

Components

Path:

Current-Folder:

Defllllhs

The

.user

profile

To

fast-list

the

folders

To

determine

the

user's

MH

directory

To find

the

default

current

folder

'+folder'

defaults

to

the

current

folder

'msg'

defaults

to

none

Qaten

'-nofast'

'-noheader'

'-nototal'

'-nopack'

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

anno-

tated

with

the

lines

Forwarded:

«date»

Forwarded:

To:

names

Forwarded:

cc:names

where

each

"To:"

and

"cc:"

list

contains

as

many

lines

as

required.

This

annota-

tion

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

<mh-dir>

/components

SHOME/.

mh.protile

<mh-dir>

/

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:

To

determine

the

user's

MH

directory

Editor:

Current-Folder:

<lasteditor>-next:

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

<lastedi-

tor>

Defaults

Contezt.

'+folder'

defaults

to

the

current

folder

'msgs'

defaults

to

cur

'-editor'

defaults

to

/bin/ned

'-no

annot

ate

,

'-noinplace'

If a

+folder

is

specified,

it

will

become

the

current

folder,

and

the

current

mes-

sage

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-file

1

[-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

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

<scan

line

for

first

message>

<scan

line

for

second

message>

<etc.>

This is

useful

for

keeping

track

of

volume

and

source

of

incoming

mail.

Eventu-

ally, 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

his-

tory.

"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

<mh-dir>

I

audit-file

P.ram.e

Compcments

Path:

Folder-Protect:

Msg-Protect:

JWaults

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

'+folder'

defaults

to

"inbox"

7th

Edition

UNIXl32V(Rand)

INC(l)

Canten

INC(t)

The

folder

into

which

the

message

is

being

incorporated

will

become

the

current

folder

I

and

the

tirst

message

incorporated

will

be

the

current

message.

This

leaves

the

context

ready

for a

show

of

the

first

new

message.

7th

Edition

UNIXl32V(Rand)

-26-

NEXf(l)

HAIlE

show

the

SYNOPSIS

[-switches

for

l]-[

-help]

DESCRIPTION

a

show

on

the

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

Profile

Components

Path:

Current-Folder:

Defaults

Context.

The

user

profile

To

determine

the

user's

MH

directory

To find

the

default

current

folder

If a

folder

is

specified.

it

will

become

the

current

folder,

and

the

message

that

is

shown

(Le.,

the

in

sequence)

will

become

the

current

message.

?th

Edition

UN1XI32V(Rand)

PICK(l) -¥:'/- PICK(l)

pick

-

select

messages

by

content

SYNOPSIS

pick

-cc

-date

[-src

+folder]

[msgs]

[-help]

[-scan]

[-noscan]

[-show]

[-noshow]

[-nofile]

[

-nokeep

]

-from

-search

pattern

-subject

-to

--component

[-file

[-preserve]

[-link]

+folder

....

[-nopreserve]

[-no1i~

[-keep

[-stay]

[-nostay]

[

+folder

... J ]

typically:

D~ION

pick

-from

jones

-scan

pick

-to

holloway

pick

-subject

ned

-scan

-keep

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

expres-

sion

(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

sub-

folder

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

sub-

sets

of

messages

in

a

folder.

7th

Edition

UNlXI32V(Rand)

PICK(l) -28- PICK(l)

mes

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

subfold-

ers.

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 %

folder

+inbox

2

inbox+

has

16

messages

(

3-

22):

cur=

3.

3 %

pick

-from

dcrocker

4 6

hits.

5

[+inbox/select

now

current]

6 %

folder

7

inbox/select+

has

6

messages

(

3-

16);

cur=

3.

8 %

scan

9

3+

6/20

Dcrocker

Re:

ned

tile

update

issue

.. .

10 6

6/23

Dcrocker

removal

of files

from

Itm

..

.

11 8

6/27

Dcrocker

Problems

with

the

new

ned

.. .

12

13

6/28

dcrocker

newest

nned

«I

would

ap

.. .

13 15

7/

5

Dcrocker

nned

«Last

week

I

asked

.. .

14 16

7/

5

dcrocker

message

id

format

«I

re

.. .

15 %

show

alII

print

16

[produce

a· full

listing

of

this

set

of

messages

on

the

line

printer.]

17 %

folder

-up

18

inbox+

has

16

messages

(

3-

22);

cur=

3;

(select).

19 %

folder

-doWn

20

inbox/select+

has

6

messages

(

3-

16);

cur=

3.

21 %

rmf

22

[+inbox

now

current]

23 %

folder

24

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

sub-

folder

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.

SHOME/. mb..protlle

The

user

profile

7th

Edition

UN1X132Y(Rand)

PlCK(l)

Pro1l1e

Components

Path:

Folder-

Protecl:

Current-Folder:

Defaults

-29-

To

determine

the

user's

MH

directory

For

prolection

on

new

folders

To find

the

default

current

folder

'-src

+folder'

defaults

to

current

'msgs'

defaulls

to

all

I-keep

+selecl'

is

lhe

default

if

no

'-scan',

'-show',

or

'-fUe'

is

specified

Conten

PICK(l)

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

fold-

er.

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

show

the

SYHOPSIS

[-switches

for

l]

[-help]

DESCRIPTION

?rev

performs

a

show

on

the

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

P.ra6le Compcments

Path:

Current-Folder:

Defaults

Context.

The

user

profile

To

determine

the

user's

MH

directory

To find

the

default

current

folder

If a

folder

is

specified,

it

will

become

current,

and

the

message

that

is

shown

(i.e.,

the

in

sequence)

will

become

the

current

message.

7th

Edition

UN1X132V(Rand)

-31-

If

AIlE

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

com-

ponent

it

finds

in

the

draft.

it

prompts

the

user

and

accepts

a

response.

A

<RETURN> will

cause

the

whole

component

to

be

left

out.

A ..

,,.

preceding

a

<RETURN> will

continue

the

response

on

the

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 <CI'RlrD>

(or

<OPEN».

Control

is

returned

to

the

calling

program.

where

the

user

is

asked

"What

now?".

See

comp

for

the

valid

options.

The

line

editing

characters

for kill

and

erase

may

be

specified

by

the

user

via

the

arguments

"-kill

chr"

and

"-erase

chr".

where

chr

may

be

a

character;

or

"'nnn",

where

nnn

is

the

octal

value

for

the

character.

(Again,

these

may

come

from

the

default

switches

specified

in

the

user's

profile.)

A <DEL>

during

message-body

typing

is

equivalent

to

<CTRL-D>

for

compatibil-

ity

with

NED.

A <DEL>

during

component

typing

will

abort

the

command

that

invoked

prompter.

None

PM61e

Components

prompter-next:

Defaults

Cantezt. None

7th

Edition

To

name

the

editor

to

be

used

on

exit

from

prompter

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

com-

posed

message

if

so

directed.

The

composed

message

is

constructed

as

follows:

To:

<Reply-To>

or

<From>

cc:

<cc>.

<To>

Subject:

Re:

In-reply-to:

Your

message

of

<Date>

<Message-Id>

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

skele-

ton

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

sin-

gle

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

<mh-dir>

/

draft

/usr

/bin/send

Profile

Components

Path:

Editor:

Current-Folder:

Defaults

The

user

profile

The

constructed

message

file

To

send

the

composed

message

To

determine

the

user's

MH

directory

To

override

the

use

of

/bin/ned

as

the

default

editor

To

find

the

default

current

folder

•

+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

mes-

sage

will

be

set

to

the

replied-to

message.

7th

Edition

UNIX/32V(Rand)

RllF(l)

NAIIE

rmf

-

remove

folder

SYNOPSIS

rmf

[

+folder]

[-help]

DRSCRIPTIOM

lUes

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

pro-

duced.

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

argu-

ment

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

hap-

pened.

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.

SHOME/.

mh~rofile

The

user

profile

Profile

Components

Path:

To

determine

the

user's

MH

directory

To find

the

default

current

folder

Current-Folder:

Defaults

Context.

I+folder'

defaults

to

current.

usually

with

confirmation

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.)

Des

The

current

message

is

not

changed

by

rmm..

so

a

nezt

will

advance

to

the

in

the

folder

as

expected.

$HOME/.

mh.profile

The

user

profile

lrofIle Components

Path:

To

determine

the

user's

MH

directory

To

find

the

default

current

folder

Current-Folder:

lefaults

Canten

'+folder'

defaults

to

current

'msgs'

defaults

to

cur

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

exam-

ple:

II

15+

16-

18

19

Date

7/

5

7/

5

7/

6

7/

7

From

Dcrocker

dcrocker

Obrien

Subject

[«Body]

nned

«Last

week

1

asked

sonle

of

message

id

format

«1

recommend

Re:

Exit

status

from

mkdir

"scan"

listing

format

in

MH

The

'+'

on

message

15

indicates

that

it

is

the

current

message.

The

'-'

on

mes-

sage

16

indicates

that

it

has

been

replied

to,

as

indicated

by

a

"Replied:"

com-

ponent

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

pars-

ing,

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

P.raftle Components

The

user

profile

Path:

Current-Folder:

Defaults

Defaults:

To

determine

the

user's

MH

directory

To

find

the

default

current

folder

'+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

lUea

Send. will

cause

the

specified

file

(default

<mh-dir>/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

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

for-

mat

is

designed

to

be

usable

by

all of

the

message

handlers

on

the

various

sys-

tems

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

redistribu-

tion

message

(see

dist

for

details).

with

"Distribution-Date:

now"

and

"Distribution-From:

user"

added.

SHOME/. m.h..protlle

P.ra61e

Components

The

user

profile

Path:

Defaults

Caaten

'file·

defaults

to

draft

'-noverbose'

'-format'

'-nomsgid'

To

determine

the

user's

MH

directory

Send.

has

no

effect

on

the

current

message

or

folder.

7th

Edition

UNIX/32V(Rand)

SEND(!) SEND(l)

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

mes-

sage

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 <RETURN>

or

<CTRL-D>.

If

a

is

entered,

1

will

clear

the

screen

before

listing

tbe

whereas

<CTRL-D> will

not.

The

switches

to

1

are

'-pH'

to

indicate

the

page

length

in

lines,

and

'-wH'

to

indi-

cate

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

<mh-

dir>

Idraft

if

it

exists.

SHOME/.

mh.protile

/binll

/bin/pr

The

user

profile

Screen-at-a-time

list

program

pr(I)

Profile

Components

Path:

To

determine

the

user's

MH

directory

To find

the

default

current

folder

Current-Folder:

Defaults

Ccmtezt.

'+folder'

defaults

to

current

'msgs'

defaults

to

cur

'-nopr'

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]

[~switches

for

t]

[-help]

pick

-cc

-date

':"from

-search

-subject

-to

--component

[-src

+folder] {tnsgs] [

-help]

[-scan]

[-noscan]

[ --show]

[-noshow]

[

-nofile]

[-nokeep]

pattern

[-file

[-preserve]

[-link]

+folder ...

[-nopreserve]

[-nolink]

]

[-keep

[-stay]

[-nostay]

[+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]

[msgs

I

[-ff]

[-header

l[

-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,arac-

terse

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

por-

tions.

The

text

for

most

formatted

components

(e.g

.•

"Date:"

and

"Message-

Id:")

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

<end-of-line>

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

delim-

iter.

This is a

cosmetic

feature

applying

only

to

locally

composed

mail.

Appendix

C

MESSAGE

NAME

BNF

msgs

msgspec

msg

msg-name

msg-range

.-

msg-sequence

.-

signed-number

.-

msgspec

msgs

msgspec

msg

msg-range

msg-sequence

msg-name

"first"

II

last"

"cur"

....

"next"

"prev"

msg"-"msg

"all"

msg'

I:"

signed-number

II

+"

"--"<number>

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

<number».

or

ending

with

u

msg

" (in

the

case

of

prey

or

last).

+<number>

forces

"starting

with

msg".

and

-<number>

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

addi-

tional

functions.

These

may

be

prepared

as

files

(known

as

shell

com-

mand

tiles

or

shell

scripts).

The following

example

is

a

useful

function

that

illustrate

the

possibilities.

Other

functions,

such

as

copying,

delet-

ing,

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.

II

Communications

of

the

ACM,

Vol. 17.

July

1974,

pp.

365-375.

3. McCauley,

E.

J.,

and

P. J. Drongowski,

"KSOS-The

Design of a

Secure

Operating

System,"

AFIPS

Conference Proceedings,

National

Com-

puter

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

Refer-

ence

Manual. The Rand

Corporation,

R-2176-ARPA,

December

1977.

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

Navigation menu

Versions of this User Manual:

Views

Navigation