An Introduction to the Berkeley Network
Computer Science Division
Department of Electrical Engineering and Computer Science
University of California, Berkeley
Berkeley, California 94720
This document describes the use of a network
machines on the Berkeley campus.
This network can execute commands on other machines,
including file transfers, sending and receiving mail,
remote printing, and shell-scripts.
The network operates in a batch-request mode.
Network requests are queued up at the source and sent in shortest-first
order to the destination machine.
To do this, the requests are forwarded through a network
of inter-connected machines until they arrive at their destination
The time this requires depends on system load, inter-machine transfer speed,
and quantity of data being sent.
The network enforces normal
demands a remote account with a password for most commands.
Information can be returned to the user in files, for later
processing, or on the terminal for immediate viewing.
A network between a number of
on the Berkeley campus has been implemented.
This document is a brief introduction to the use of this network.
Information which is specific to the local network has been
gathered into Appendix A.
The new user should read both this introduction and Appendix A in order
to learn to use the network effectively.
This document is subdivided into the following sections:
Appendix A: The Network at Berkeley
Appendix B: Getting Started \(em An Example
This manual is written in terms of three mythical machines,
Specific names at Berkeley are in Appendix A,
along with more local information.
The network provides facilities for issuing a command on one
machine) which is to be executed on another (the
Network commands are available to transfer files from one machine
to another, to send mail to a user on a remote machine,
to retrieve one's mail from a remote account,
or to print a file on a remote lineprinter.
These commands are described below, as is the more general
command which allows users to specify the name of some command
or shell script to be executed on a remote machine.
Network requests are queued up on the local machine and sent to the remote
machine, forwarded through intermediate machines if necessary.
Most of the network commands require that you have an account on
If a remote account is not needed for a particular command,
it will be noted in the following discussion.
The first example introduces procedures and responses which are applicable
Suppose that you have accounts on both the \*X and \*Y machines and that you are
presently logged into the \*X machine.
If you want to copy a file named `file1' from your current
directory on machine \*X to machine \*Y (the
machine), use the command:
The net will make a copy of `file1' in your login directory
(The `\*Y:' will not be part of the filename on the \*Y machine.)
In order to verify your permission to write into the \*Y account, the
command will prompt you with:
You should respond with your login name on the Y machine,
followed by a carriage-return.
If you have the same login name on both machines, just type a carriage-return.
Next a password will be requested:
Now type in your password followed by a carriage-return.
command will make a copy of your `file1' in a queue destined
for the \*Y machine, and will then return.
Likewise if you wanted to transfer a file named `scan.p' from \*Y to \*X,
% netcp \*Y:scan.p scan.p
would place that file in your current directory on \*X.
The network will ``write'' you when it has executed
your request (if you are still logged in),
or will ``mail'' you a message (if you are not).
(I) command to disallow the interruption and thus force mail to be sent.
A typical message might look like this:
Message from your-name on \*Y Machine
(command: netcp file1 \*Y:file1, sent April 1 18:03, took 10 min 3 sec)
The message includes the time you sent the command on machine \*X.
The network response will tell you if it was unable to execute the
remote command successfully by returning an error message some time later.
If, for example, you type the wrong password, you will get the response
Message from your-name on \*Y Machine
Error: Cmd: netcp file1 \*Y:file1 Message: bad login/password your-name
command is actually a generalization of the
Programmers Manual (Version 7 only).
\fBnetcp\fR [\fB\-l\fI login\fR] [\fB\-p\fI password\fR] [\fB\-n\fR] [\fB\-f\fI] fromfile tofile\fR
can be local or remote files
(if both are remote, they must be on the same machine).
A filename which is not a full pathname
is either from the current directory on the local machine
or your login directory on the remote machine.
options may be used to specify your remote login name and password
If the password contains shell meta-characters, it must be in quotes.
(These options are useful in shell scripts,
but be sure to make the shell script readable only
by yourself if you've got passwords in it!)
option prevents any confirmation or error messages from being returned.
option forces prompting for a remote user name and password,
even if they are set by other options or are in the ``.netrc'' file
(see ``Setting Defaults'' below).
Transferred files may or may not have the correct file protection mode;
When files are to be brought from a remote machine,
they are created zero-length at the time the command is issued;
when they arrive, they assume their true length.
% netcp\ \ file1\ \ \*Y:file1 copy `file1' from the current directory to \*Y
% netcp\ \ \*Y:file1\ \ file1 copy `file1' from \*Y to the current directory
% netcp\ \ \*Z:file1\ \ \*Z:file2 \fIcp\fP command on remote machine
% netcp\ \ \*X:lex.c\ \ \*Y:lex.c copy from \*X to \*Y (one of \*X or \*Y must be local)
% netcp\ \ \*Y:subdir/file1\ \ file1 copy from a sub-directory
% netcp\ \ file1\ \ file2 an error\(em use the \fIcp\fP command
To see where your command is in the queue, type
a typical output of which looks like:
LocalName(Remote) Mach Length Code Time Command
yourname(yourname) \*Y 100 b99999 Mar 23 18:05 netcp file1 \*Y:file1
The format is similar to that of the
The files are sent one at a time, in the order listed.
tells you the queue is empty, your request has been sent already.
The queues for different destinations are totally separate.
will list just the queue destined for the \*Y machine.
summarizes requests from other users.
will print the requests from all users.
If you want to cancel your net request, and ``b99999''
example above) is your ``Code,'' use the command
which will remove the request (if it hasn't already been sent).
will remove all your net requests in the queues on the local machine
(you must have made the request in order to remove it).
To send mail to remote machines, use the
command with the remote account prefixed by the destination machine's
``\*Y:schmidt'', for example, refers to an account ``schmidt'' on the \*Y machine.
The full sequence is illustrated below:
\ \ \ \ {your message to user ``schmidt'' }
This will send to user ``schmidt'' on the \*Y machine the text you type in.
As with intra-machine mail, the message is terminated by a control-d.
You do not need an account on a remote machine to send mail to a user there.
It is also possible to read your mail on remote machines.
From the \*X machine, the command
copies your mail on the \*Y machine to a file ``mbox.\*Y''
in your login directory on the \*X machine.
The previous contents of ``mbox.\*Y'' are lost.
\fB\-l\fP, \fB\-p\fP, \fB\-n\fP and \fB\-f\fP options just like
If a machine is not specified, the default machine\(dg is used.
\(dg (see ``Setting Defaults'' below)
When you login on the remote machine, the mail will still be there,
Remote lineprinters can be used with the
\fBnetlpr\fR [\fB\-m\fI machine\fR] \fIfile1 file2 ... filen\fR
which sends the files its arguments represent to the lineprinter on
It will prompt you for an account and password.
The \fB\-l\fR, \fB\-p\fR, \fB\-n\fR and \fB\-f\fR options may be supplied,
Copies of the files are not made in the remote account.
The above commands all use one more general command\(emthe
command which has the following form:
\fBnet \*a\-m\fI machine\*b \*a\fB\-l\fI login\*b \*a\fB\-p\fI password\*b \*a\fB\-r\fI file\*b \*a\fB\-\*b \*a\-n\*b \*a\-f\*b\fI command\fR
sends the given command to a remote machine.
The machine may be specified either with the
option or in the ``.netrc'' file
(for the specific names, see Appendix A).
If not specified, a default is used.
\fB\-l\fP, \fB\-p\fP, \fB\-n\fP and \fB\-f\fP are as explained above for the
The \fB\-r\fP option indicates the local
which will receive the output (the standard output and standard error files) of
when it is executed on the remote machine.
By default this output is written or mailed to you.
Thus, for example, to find out who is on the \*Y machine when you are
logged in on the \*X machine,
execute the following command:
command on the \*Y machine;
the response will be written or mailed to you.
% net \-m \*Y \-r resp "who"
will take the output (result)
and return it to you in file `resp' on the local machine.
If instead you want the result of the
command to remain on the \*Y machine the command
% net \-m \*Y "who >resp"
will create a file `resp' in your login directory on the \*Y machine.
It is a good idea to put the command in quotes, and it
be in quotes if I/O redirection (<, >, etc.) is used.
If you do not specify the remote machine explicitly (or in the ``.netrc''
file, explained below), the default machine will be used (see Appendix A).
option indicates that standard input from the
local machine is to be supplied to the command executing remotely
% net \-m \*Y \- "mail ripper"
\ \ \ \ { message to ripper }
\ \ \ \ { message to ripper }
The net command also has other options not documented here.
Programmer's Manual sections for more details.
Instead of repeatedly typing frequently-needed options
for every invocation of the various network commands, the user may supply
in his login directory a file ``.netrc'', which contains the repeated
The ``.netrc'' file is typically used to specify login names
on remote machines, as well as other options.
An example of such a file is given below:
machine \*Y, login dracula
machine \*Z login dracula
This example sets the default machine to \*Y
so that for net commands where a remote machine is not explicitly specified
the command will the executed on the \*Y machine.
The second and third lines indicate
for the \*Y and \*Z machines a login name of ``dracula''
should be used to network commands.
The complete list of options is:
Option Parameter Default Comment
\fBdefault\fP mach. name See App. A provides default remote machine
\fBlogin\fP name localname login name for remote machine
\fBpassword\fP password (none) password for remote login name
\fBcommand\fP command (none) default command to be executed
\fBwrite\fP yes/no yes if possible, write to user
\fBforce\fP yes/no no always prompt for name and password
In setting up the ``.netrc'' file, if the ``default'' option is present,
it must be the first line of the file.
Multiple spaces, tabs, newlines, and commas
serve as separators between words.
The information for each machine starts with the word
``machine'' and the machine name and continues
one or more lines up to another machine indication
(or the end of the file).
Double quotes (") must surround passwords with blanks or special
If your ``.netrc'' file has a password in it, the file should be set
(I) command to prevent other people from reading it.
The system managers do not recommend putting the passwords
or in shell-scripts with the \fB\-p\fP option (even with mode 0600)
as an illicit super-user could read your ``.netrc'' file
and gain direct access to all your remote accounts.
If you put a remote password in a file, you must be prepared to change
your passwords if a security breach occurs on any net machine.
The surest way to prevent this inconvenience is to not put your
remote passwords in a file at all!
The file ``/usr/net/logfile'' has a trace of the most recent
requests and responses, each line of which is dated.
Lines indicating ``send'' show the file name sent;
lines indicating ``rcv'' show commands executed on the local machine (C: ),
their return code (R: ), and their originator.
For example, on the \*Y machine, the logfile:
Feb 28 10:29: rcv \*X: neil (neil) R: 0 C: netcp design \*Y:design
Feb 28 10:43: sent to \*Z: tuck (z00466, 136 bytes, wait 2 min 3 sec)
Feb 28 11:05: rcv \*X: bill (bill) R: 0 C: netcp structures \*Y:structures
In this example, there are two
commands sending files from the \*X machine to \*Y, each from a different user.
The single command sent was originated here by ``tuck'' and is 136 bytes long;
the command that was sent is not listed.
will print the last few lines of this file.
is an integer will print the last
Bob Fabry, Bill Joy, Vance Vaughan, Ed Gould, Robyn Allsman,
Bob Kridle, Jeff Schriebman and Ricki Blau of Berkeley,
and Dave Boggs of X\s-2EROX\s0 P\s-2ARC\s0
for their help in making this network possible.
The Configuration (April 1, 1979)
The Current State of the Berkeley \s-2UNIX\s0 Network
Machine Internal Connected Baud Default
Name Name To Rate Machine
.de bo \" a few box macros
.de zt \"generate up to 4 lines of centered text.
.ll \\$2n+\\n(.iu \"$2 is width of field in n's
.sp \\$1 \"$3,$4,$5,$6 are text lines
.ce 4 \"$1 is prespace amount in V's
.nr v 4 \" vertical dimesion of box (in v's)
.nr h 14 \" horizontal dimenstion of box (in n's)
.in -56n \" back to start on left, draw boxes
.in -56n \" back to start on left, draw vert lines
.in +7n \" next vert Cory-VAX
.in +28n \" next vert C-E
.in +28n \" next vert C-SRC
If a path exists from the local machine to the requested remote
machine, the network will forward the request to the correct machine.
Thus Cory users may communicate with A, D and E,
as well as C and VAX (with a degradation in speed
because of the intermediate machine).
(net, netq, netrm, netlog, netcp, netmail, netlpr)
are all documented in the
under NEW on the Cory and VAX, and under NET on the Computer Center
% man new netq {on Cory or VAX}
% man \-net netq {on CC machines}
There are two more documents available:
System Description \- Berkeley Net
The Manual is intended for the systems staff who will maintain the network.
the history of the project, discusses the design, and list future plans.
There is an up-to-date news file:
% news net {on Cory and VAX machines}
% help net {on CC machines}
which prints news about the network, dated and with the most recent news first.
Programmer's Manual, section I, has information on the
chmod, cp, mail, mesg, who, and write
commands mentioned in the text.
command has information about file protections:
% news access {on the Cory machine}
% help permissions {on the CC machines}
There is a built-in character limit
of 100,000 characters per single transmission, which cannot be overridden.
Longer files must be split into smaller ones in order to be sent.
The 1200 Baud links (over which the network sends requests) seldom transmit
any faster than 50 characters per second,
and can slow to a fraction of that in peak system loading periods.
This is due to an expansion of
the data packets to accomodate a seven-bit data path,
wakeup time on the machines, and the packet sent in acknowledgement.
Heavy file transfer is faster by magnetic tape.
On the VAX the net commands are all in `/usr/new'.
Your search path on the VAX should be set to include the directory `/usr/new';
otherwise you will have to prefix all net commands by `/usr/new',
Users who do not have accounts on remote machines may still execute
certain commands by giving a remote login name of ``network'',
The commands currently allowed are:
between Computer Center machines do not require a remote account.
If no machine name specification is in the front of a full path name,
the first four characters are checked and the machine
is inferred from that if possible.
netcp file1 /ca/schmidt/file1
the second file name is equivalent to ``C:file1'', if you are ``schmidt''
There is a file ``VAX:/usr/net/net.users'' of users who
will get mail specifically about the network.
If you would like to be on it, send mail to ``VAX:schmidt''.
The network creates a heavy load on the system and thus is expensive to
run. If general user throughput is adversely affected, a charge will be
implemented on the Computer Center machines.
When transferring files, quota overflow will result in a partial copy,
so you should check the space requirements of the file being sent.
Bugs in systems at Berkeley (As of April 1, 1979)
On the Computer Center machines,
if the ``mail'' command prints an error message such as ``Can't send to ...'',
try using the ``sendmail'' command in place of ``mail'' with the
The C shell on the Computer Center machines has a bug where background
C shell scripts can't find home directories, and thus do not read
On the Computer Center machines,
if you change your shell prompt,
obsolete shells may print the prompt incorrectly,
In the Pascal shell (/usr/pascal/sh):
for example, is the correct way to to set a shell prompt to ``P''.
In the C shell (/bin/csh), it is
On the Computer Center machines, you may not
net queue files created by
or the remote versions of
The file mode should be preserved by
Comments and bug discoveries are encouraged and can be sent by
local or remote mail to ``schmidt'' on the VAX machine.
Getting Started \(em An Example
The best way to start out is to follow this example.
Suppose you're a Cory user, and you have accounts on the A and VAX machines.
Add a file ``.netrc'' (mode 600) to your login directory, as in
machine A login \fIyourNameOnA\fP
machine VAX login \fIyourNameOnVax\fP
(If ``default'' occurs, it must be the first line of the file.)
if you are on the VAX, you have in your search path the directory `/usr/new'.
Otherwise, on the VAX you will have to prefix all commands by `/usr/new/'
on the Computer Center machines, if you choose to set your shell prompt,
you have done so correctly (details in Appendix A).
some undetermined time later you will
have written (or mailed) to you the output from the command
executed on the VAX machine.
The adventuresome may try:
with the effect of being routed more slowly through an intermediate link in the