PWB1/usr/news/pibs
PY-77-05(PWB PIB) 2/22/77 PY-77-05(PWB PIB)
TO:
All BISP Programmer's Workbench (PWB) Users
SUBJECT:
Release 4.0 of SCCS/PWB
DISPOSITION:
PWB User's Manual (User's Documentation, Book One)
On Wednesday, February 18, 1977, release 4.0 of SCCS/PWB was
installed on the BIS PWB systems.
The existing release 3 commands will continue to be available
until further notice. The new (release 4.0) commands are avail-
able as admin, get, prt, and delta.
User documentation for the release 4.0 commands is available
under the man(I) command, and will be issued at a future time
to the PWB User's Documentation subscription list.
Release 4 SCCS/PWB files have different format than release 3
SCCS/PWB files. Release 3 files may be identified by a "magic
number" of 61000(8), while release 4 files have a magic number of
64001(8). Attempting to apply release 3 commands to release 4
files, or release 4 commands to release 3 files will produce a
diagnostic message.
1. MAJOR INCOMPATIBILITIES
1.1 File Format and Prt
The file format of SCCS files has been completely changed.
Release 4 SCCS files are ASCII files (i.e., they are a sequence
of newline terminated ASCII strings); see sccsfile(V).
ASCII files have many advantages over binary (release 3) files.
Any PWB command which can be used on normal text files can now be
used on SCCS files. In particular, grep/sed type of commands are
particularly attractive for use with SCCS files. (The file for-
mat of release 4 files was designed to allow the extraction of
the various portions of a release 4 file with either the grep or
sed commands.) ASCII files also imply that when the SCCS file
itself must be changed (patched), it can now be done by using the
text editor ed(I). Finally, the cat(I) command can be used
to "dump" an SCCS file.
Due to the change in file format, the output format of the
prt(I) command has changed drastically; see prt(I).
- 1 -
PY-77-05(PWB PIB) 2/22/77 PY-77-05(PWB PIB)
1.2 Non-propagating Deltas
The deltas of an SCCS file form a tree. In release 3, these
trees are restricted to trees where the only nodes which can have
more than one successor are those nodes which already have one
successor, and the level number of that successor is 1. The
number of additional successors is limited (typically to one).
The nodes on the additional branches are "non-propagating" del-
tas. For example, given deltas 1.1, 1.2, 1.3, 3.1, and 3.2, a
delta may be added to the tree at 1.3, forming a new branch. The
new delta will be identified as 1.4 and will be non-propagating.
One, and only one, more delta may be added to the tree at 1.3,
forming yet another new branch. This new delta will be identi-
fied as 2.1 and will also be non-propagating. In release 3 it is
not possible to ascertain the predecessors of a given delta (one
would expect delta 2.1 to precede delta 3.1, however, in the
example above this is not true).
The restrictions on the number of branches that may exist in the
tree of deltas of an SCCS file has caused some problems for users
of SCCS. The following example illustrates the most common prob-
lem: Given deltas 1.1, 1.2, 1.3, 2.1, and 2.2. The release 1
source has a bug that should be fixed. A programmer begins to
fix the bug creating 1.4 and 1.5. The bug is not completely
fixed and a very serious bug is reported by a user of the pro-
gram. The fix to this more serious bug should be made directly
after 1.3, but this is not possible. The new fix is instead made
after 1.5! More often than not, this method of source update
will create additional problems for the user of the program. To
prevent problems of this nature, release 4 of SCCS allows the
tree of deltas to take on the shape of an arbitrary tree. This
additional freedom necessitates a change in the method of number-
ing deltas. All deltas along the "main line" (or "trunk") of the
tree retain the "release.level" numbering. Also, in release 4,
delta 2.1 will always precede delta 3.1 (see below).
The numbering of so-called "non-propagating" deltas has com-
pletely changed. (The term "non-propagating" has been discarded
in release 4.) Deltas in release 4 are identified by an SCCS
identification string (SID). The SID consists of two components
("release.level") for normal deltas, and four components
("release.level.branch.sequence") for so-called "non-propagating"
deltas. A new keyletter is available on the get command which
provides for upward compatibility of the defaults for SIDs. The
-t keyletter on get will access the most recent ("top") delta in
the specified release. Thus, if one specifies "get -t -r60
s.file", and the newest release 60 delta is 60.8.1.3, then
60.8.1.3 will be accessed.
In release 4 whenever a delta already has a successor with a two
component (R.L) SID (e.g., delta 1.2 may have successors 1.3,
1.4, ..., 2.1, 2.2, ...), the SID of the new successor always has
four components. The new successor is identified by the "branch"
- 2 -
PY-77-05(PWB PIB) 2/22/77 PY-77-05(PWB PIB)
component of the SID (each additional successor to a given delta
creates an additional branch in the tree of deltas). The value
for the branch component is simply one more than the highest
existing branch component for the same prefix (R.L). The value
for the first branch is 1. (E.g., a delta added to 1.2 when 1.3
exists will get the SID 1.2.1.1.) The last component is the
sequence number within a given branch.
With this algorithm it is not possible to enumerate all predeces-
sors of a given delta, if the SID of that delta has four com-
ponents. The branch component provides limited information.
(The second successor of delta 4.6.8.2 is 4.6.X.1, where X is a
number greater than 8.)
The SCCS identification keywords %R% and %L% are retained (the
values of the first and second components of the SID are the sub-
stitutions, respectively), and SCCS identification keywords will
be introduced for the branch and sequence components (%B% and
%S%, respectively). The %I% keyword (equivalent to
%R%.%L%.%B%.%S%) should be used in place of the separate com-
ponent identification keywords.
The following tables and notes give the rules of the new algo-
rithm (in the discussion that follows a "main line" delta is any
delta with a two component SID):
The current (release 3) algorithm can be described as
SID specified SID actually gotten new SID (if get -e) Notes
R R.MAXL R.MAXL+1 1
R MAXR.MAXL R.1 2
R.L R.L not allowed 3
The new (release 4) algorithm can be described as
SID specified SID actually gotten new SID (if get -e) Notes
R R.MAXL R.MAXL+1 4
R MAXR.MAXL R.1 5
R R.MAXL R.MAXL.MAXB+1.1 6
R.L R.L R.L+1 7
R.L R.L R.L.MAXB+1.1 8
R.L.B R.L.B.MAXS R.L.B.MAXS+1 9
R.L.B.S R.L.B.S R.L.B.S+1 10
R.L.B.S R.L.B.S R.L.MAXB+1.1 11
Notes
1. This is the most common action (the SID is usually left off
and the default release is used). The delta R.1 must exist,
if it does not then this is case 2 (see next note).
- 3 -
PY-77-05(PWB PIB) 2/22/77 PY-77-05(PWB PIB)
Example:
get -e -r1 s.x
(1.1 must exist)
1.MAXL actually gotten
New SID = 1.MAXL+1
2. This corresponds to beginning a new release. The delta R.1
does not exist.
Example:
get -e -r2 s.x
(2.1 does not exist)
1.MAXL actually gotten
New SID = 2.1
3. A specific delta is named; this delta must exist. This form
is illegal for a get -e.
Example:
get -r3.8 s.x
(3.8 must exist)
3.8 actually gotten
4. Analogous to note 1 above. The delta R.1 must exist, if it
does not then this is case 5 (see next note). The delta
R.MAXL has no "main line" successors; if it does then this
is case 6 (see below). This last condition is not upward
compatible with release 3 SCCS/PWB.
Example:
get -e -r1 s.x
(1.1 must exist)
1.MAXL actually gotten
New SID = 1.MAXL+1
5. Analogous to note 2 above. The delta R.1 does not exist.
Example:
get -e -r2 s.x
(2.1 does not exist)
1.MAXL actually gotten
New SID = 2.1
6. Analogous to the creation of a release 3 "non-propagating"
delta. The delta R.MAXL has a "main line" successor. This
situation is not upward compatible with release 3 SCCS/PWB.
Example:
get -e -r1 s.x
(1.MAXL = 1.8; 2.1 exists;
1.8.1.1 does not exist)
1.8 actually gotten
New SID = 1.8.1.1
- 4 -
PY-77-05(PWB PIB) 2/22/77 PY-77-05(PWB PIB)
7. A specific delta is named; this delta must exist. In
release 4 this form is legal for a get -e. The delta R.L
has no successors; if it does (or the user supplies an addi-
tional keyletter [-b]) then this is case 8 (see next note).
Example:
get -e -r1.3 s.x
(1.3 exists and has no successors)
1.3 actually gotten
New SID = 1.4
8. A specific delta is named. Either the delta R.L has a suc-
cessor, or the user has supplied an additional keyletter [-
b]).
Example:
get -e -r1.3 -b s.x
(1.3 exists and 1.3.1.1 does not exist)
1.3 actually gotten
New SID = 1.3.1.1
OR
get -e -r1.3 s.x
(1.3 exists and has a successor;
1.3.1.1 does not exist)
1.3 actually gotten
New SID = 1.3.1.1
9. Analogous to notes 1 and 4 above. The delta R.L.B.1 must
exist.
Example:
get -e -r1.3.1 s.x
(1.3.1.1 must exist)
1.3.1.MAXS actually gotten
New SID = 1.3.1.MAXS+1
10. Analogous to note 7 above. A specific delta is named. The
delta R.L.B.S has no successors; if it does (or the user
supplies an additional keyletter [-b]) then this is case 11
(see next note).
Example:
get -e -r2.3.8.4 s.x
(2.3.8.4 exists)
2.3.8.4 actually gotten
New SID = 2.3.8.5
11. Analogous to note 8 above. Either the delta R.L.B.S has a
successor, or the user has supplied an additional keyletter
[-b]).
- 5 -
PY-77-05(PWB PIB) 2/22/77 PY-77-05(PWB PIB)
Example:
get -e -r2.3.8.4 s.x
(2.3.8.4 exists and has a successor;
2.3.9.1 does not exist)
2.3.8.4 actually gotten
New SID = 2.3.9.1
2. FEATURES NO LONGER SUPPORTED
Besides what was mentioned above, the following are no longer
supported:
2.1 Admin
1. The d keyletter; there is no longer a "description field" in
an SCCS file. See however "NEW FEATURES" below.
2. The p keyletter; there is no longer a "person field" in an
SCCS file. See however "NEW FEATURES" below.
3. The l and u keyletters; locks are not supported. The floor
and the ceiling have, in the past, been more than enough
additional protection.
4. The y keyletter; There is no longer a "default release".
The highest release that has deltas is always the "default
release".
2.2 Prt
As described above, because of the change in the SCCS file for-
mat, the output format of prt(I) (q.v.) has changed drasti-
cally. The header and release table are non-existent in release
4. The delta table and the body have changed formats. The p and
x keyletters are no longer supported.
2.3 Get
The %X% ("non-propagating" flag), and %P% identification keywords
are no longer supported. The %S% identification keyword has a
new meaning; see below.
2.4 Delta
The a keyletter is no longer supported ("non-propagating" deltas
don't exist in release 4). The l and h keyletters are no longer
supported.
- 6 -
PY-77-05(PWB PIB) 2/22/77 PY-77-05(PWB PIB)
3. FEATURES THAT HAVE CHANGED
3.1 Admin
1. The type, floor, and ceiling fields are implemented as flags
(see "NEW FEATURES", below).
2. The "list of users who may add deltas" is now a list of
login names (strings). The use of a numeric value on an e
keyletter does not have the same meaning as in release 3 (in
release 4, a numeric string is simply a string). Note that
the use of login names allows distinction between two or
more users who have the same user ID.
3. The z keyletter recomputes the checksum (in release 3 admin
simply zeroed the checksum).
3.2 Prt
The format of the delta table and the body have changed, and the
meaning of the s keyletter has changed; see prt(I). The
interpretation of the y keyletter has changed slightly: the y
keyletter takes either an SID as an argument, or no argument at
all. With a specific SID, processing printing of the delta table
will stop with the printing of the named SID's entry. If no
argument is specified, just the first delta table entry is
printed.
3.3 Get
1. The value of an r keyletter argument is now an SID. See
above or get(I) for defaults.
2. Non-numeric characters may separate the various 2 digit
pieces of a cutoff date-time. This feature is most useful
for nesting get commands within send(I) input; see
get(I).
3. The syntax of a <list> (value of an i or x keyletter) has
changed to allow for "branch" and "sequence".
4. The format of the l-file has changed drastically; see
get(I).
5. The format of the m keyletter output is: SID, followed by a
horizontal tab, followed by the text line. The
reform(I) command will be changed so that its s
keyletter will take all characters up to the first tab,
throw away the tab, place the characters in columns 73
through 80, and if the text extends beyond column 80, place
an "*" in column 80. In addition, +t will be assumed.
- 7 -
PY-77-05(PWB PIB) 2/22/77 PY-77-05(PWB PIB)
6. The "Non-prop" messages no longer are output because there
are no longer "non-propagating" deltas.
7. The content of the n keyletter output is changed slightly.
Instead of the g-file name, the value of the %M% identifica-
tion keyword is used (see next item).
8. The value of the %M% identification keyword is either the
value of the m flag (see "NEW FEATURES", below), or, if
there is no m flag in the file, the g-file name.
9. The %S% identification keyword is no longer the description;
it is now the "sequence" component of the SID being
accessed.
10. The replacement text for the %Z% identification keyword has
been changed to "@(#)" to allow it to be transmitted via
rje, and printed on IBM printers. The what(I) command
has already been changed to recognize both the old %Z%
replacement and the new %Z% replacement.
11. The format of the p-file has changed drastically; see
get(I).
3.4 Delta
The prompt for "history? " has been changed to a prompt for "com-
ments? ". Also, if there is a v flag in the file, delta will
prompt for Modification Request (MR) numbers in addition to
prompting for comments. If the v flag has a value, then that
value is taken to be the name of program which can verify the
correctness of the MR numbers; see delta(I).
4. NEW FEATURES
4.1 Improved Error Handling
In release 4, whenever a command detects a fatal error when pro-
cessing a file, processing on that file will be terminated, but
the command will attempt to continue with any subsequent files.
This feature is most useful when checking for corrupted SCCS
files.
4.2 Checking for Corrupted SCCS Files
The h keyletter on the admin(I) command causes admin to
check the stored checksum against a computed checksum. Admin is
now the recommended program to be used for checking for corrupted
files.
- 8 -
PY-77-05(PWB PIB) 2/22/77 PY-77-05(PWB PIB)
4.3 Flags
There are seven flags in release 4 SCCS files. All may be set,
removed, or changed with admin(I). See admin(I) for
the meanings of the different flags.
4.4 User Text
A portion of an SCCS file is reserved for arbitrary text supplied
by the user. This text is changed with the admin(I) com-
mand. This portion of the file is intended to take the place of
the release 3 description and person fields.
4.5 Prt
Prt(I) has new keyletter arguments to print the new pieces
of an SCCS file; see prt(I).
4.6 Get
4.6.1 Multiple Get -e Commands It is possible for more than one
get-edit-delta sequence to be active at the same time, provided
that no two gets accessed the same SID, and that no two deltas,
when made, will create the same SID. A diagnostic message will
be issued whenever one of these conditions is violated, and the
get for the file in question will be terminated. A warning will
be produced whenever another user has already done a (non-
interfering) get -e. The format of the p-file has changed drast-
ically as a result of this new feature; see get(I). If the
same user has done more than one get -e then that user must use
the -r keyletter on delta until there is no ambiguity about which
delta is to be made; see delta(I).
4.6.2 -b keyletter The -b keyletter is used with the -e
keyletter. It forces the SID of the new delta to be in a new
branch. It is only allowed if the b flag is present in the file;
see admin(I).
4.6.3 -g keyletter The -g keyletter suppresses the actual get-
ting of source. It may be used to retrieve an l-file, or to ver-
ify the correctness of a given SID ("get -rSID -s -g s.file" will
simply set the shell variable $r to 0 if the SID exists in the
file, or 1 if the SID does not exist in the file).
4.6.4 -t keyletter The -t keyletter is used to request the most
recent ("top") delta in a release. It provides for compatibility
of use between release 3 and release 4. (If 60.8.1.3 is the
newest delta with a release of 60, then a "get -t -r60 s.file"
will access 60.8.1.3.)
4.6.5 Include/Exclude In release 4, the -i and the -x arguments
are recorded in the p-file and are used when making the delta
(i.e., when delta regenerates the g-file to determine what
- 9 -
PY-77-05(PWB PIB) 2/22/77 PY-77-05(PWB PIB)
changed, it will include (exclude) those deltas specified by the
-i (-x) arguments from the p-file). Thus, when a delta is made
on a branch (say, for an old release of the program), and it is
desired to include the fix in the "main line", the -i keyletter
will include the fix without any noticeable increase in the size
of the SCCS file.
Whenever two deltas conflict in what they are trying to insert or
delete (for example, an insert comes along in the middle of an
older delete), get will generate a warning message identifying
the line where the conflict begins, and later, identifying the
line where the conflict ends. With these warning messages it is
possible to use the include/exclude facilities without fear of
unwanted changes being made to a g-file.
4.7 Delta
Delta will use the diff(I) program to determine what changed
between two files of text.
The "ignore" capability is intended to replace the release 3 pro-
cess of acknowledging non-propagating deltas. Any delta which is
not applied and not ignored will be identified in the l-file. A
delta should be ignored once the problem which caused the crea-
tion of the delta has been solved, or found to be non-existent.
A delta which is included need not be ignored since an included
delta is applied.
Whenever a delta is made, the number of lines inserted, deleted,
and unchanged will be recorded in the delta table entry for the
new delta.
4.8 Lockout
An additional file has been introduced which will serve as a
semaphore to any other program attempting to update the SCCS
file. This file is known generically as the z-file.
5. CONVERSION FROM RELEASE 3 TO RELEASE 4
Release 3 files are converted to release 4 files by executing the
command:
scv name ...
where "name" is any file name argument acceptable to the release
3 get command (including directory names, or a name of "-"). The
scv command prints the name of each file processed. After a file
has been processed, the release 3 file is replaced with the
release 4 file. The release 3 file is unlinked. If one desires
to retain a copy of the release 3 file, one must either make a
link (see ln(I)) or a copy (see cp(I)) of the release 3 file. DO
NOT SAVE OLD SCCS FILES UNLESS YOU'RE ONLY EXPERIMENTING WITH
RELEASE 4 - ONCE A RELEASE 4 DELTA IS MADE THE 2 FILES WILL BE
- 10 -
PY-77-05(PWB PIB) 2/22/77 PY-77-05(PWB PIB)
OUT OF SYNC.
Release 3 p-files are not acceptable to release 4 commands.
Therefore, either (release 3) delta should be executed before
scv, or the p-file should be removed. Scv will not convert a
release 3 SCCS file if there is a p-file outstanding.
The "person" and "description" fields will be copied to the "user
text" portion of the file. The "type" will be preserved. The
number of lines inserted, deleted, and unchanged for each delta
is not computed by scv, hence these data are recorded in the con-
verted file as "?????". The SIDs of "non-propagating" deltas
have, of course, four components.
Finally, only one login name per user ID will be placed on the
"list of users who may add deltas". If you use this feature of
SCCS and share user IDs among different login names, you must add
the other login names to the user list with the admin(I)
command.
Additional copies of this PIB may be obtained from any PWB com-
puter by use of command "man pib 77 05".
- 11 -
PY-77-XX(PWB PIB) 5/24/77 PY-77-XX(PWB PIB)
TO:
All BISP Programmer's Workbench (PWB) Users
SUBJECT:
Installation of PWB/UNIX Edition 1.0
DISPOSITION:
PWB User's Manual (User's Documentation, Book One)
"The air is humming,
And something great is coming.
Come on, deliver to me ..."
- West Side Story
L. Bernstein & S. Sondheim
PWB/UNIX Edition 1.0 is currently being tested on UNIX A. It
will be installed on the other BISP PDP-11's as follows:
UNIX D: 6/6/77
UNIX B,F: 6/13/77
PWB/UNIX Edition 1.0 will be available to the rest of the world
on 7/1/77. It will not be installed on Systems C and E; those
users are moving to the new Systems G and H in July, and they
will get PWB/UNIX Edition 1.0 at that time.
There are a number of differences between PWB/UNIX Edition 1.0
and the "old" version currently installed on PWB Systems B-F.
These differences range from major to trivial. The following
describes the known differences:
PWB/MM Macros:
PWB/UNIX Edition 1.0 has a new version of the Memorandum
Macros. The nroff output of PWB/MM moves closer to the
troff output appearance.* The new default nroff appearance
incorporates the following:
⊕ The first two heading levels are stand-alone, and both
have a blank line following the heading text. Previ-
ously, only the first had a blank line following the
text. Specifically, the default value for the Hs
register is 2, instead of 1.
⊕ The text for all heading levels will be underlined.
________
* In fact, the new nroff version of PWB/MM is based on the
existing troff version.
- 1 -
PY-77-XX(PWB PIB) 5/24/77 PY-77-XX(PWB PIB)
⊕ The indentation for dash lists and bullet lists is the
same as for the paragraph indentation. Previously,
these lists were indented two spaces.
⊕ .SA 0 (no right adjustment) is the default for nroff.
nroff:
PWB/UNIX Edition 1.0 has a new ("C") version of nroff. It
is vastly different from the previous (assembler) version.
The nroff ``language'' is now closer to troff than before.
In fact, both nroff and troff are described in the same
document -- "Nroff/Troff User's Manual", by J. F. Ossanna,
October 11, 1976.
"New Text Formatting Software for the PWB Systems", Memoran-
dum for File, February 2, 1977, File 39380-6 by D. W. Smith,
gives a complete description of the differences between the
old and new versions and how to modify existing macro pack-
ages for the new nroff.
After PWB/UNIX Edition 1.0 has been installed, the old ver-
sion of nroff will reside in onroff for a period of time.
tbl:
The PWB/UNIX Edition 1.0 version of the program to set
tables of data, tbl, has been greatly improved. Its
features are described in "Tbl -- A Program to Format
Tables" by M. E. Lesk, revised printing dated
August 10, 1976. Its newest features include the ability to
draw boxes around the columns of data and the ability to
specify columns of filled text.
The way in which the column specifications are written has
changed from the previous version. Any document using the
previous specifications must be converted. The program
cvtbl will do this conversion. For example:
cvtbl file...
will convert the column specifications in the given file(s).
The tbl manual mentions certain features that are functions of
the -ms macro package,* and not of tbl itself:
⊕ The .TC synonym for .T& must not be used. It conflicts
with the .TC macro of PWB/MM.
⊕ The .T# and .TH macros are not yet implemented in
PWB/MM. Thus, multi-page boxed tables cannot be done.
The new tbl works only with the new nroff and troff. That
is, new tbl is not compatible with onroff. After PWB/UNIX
________
* M. E. Lesk, "Typing Documents on UNIX".
- 2 -
PY-77-XX(PWB PIB) 5/24/77 PY-77-XX(PWB PIB)
Edition 1.0 has been installed, the old version of tbl will
reside in otbl for a brief period.
neqn:
The PWB/UNIX Edition 1.0 neqn has been revised to use the
features of the new nroff. Some new math setting facilities
have also been added. For documentation, see "Typesetting
Mathematics -- User's Guide" by B. W. Kernighan and L. L.
Cherry, June 2, 1976. The program neqn cannot
work with onroff. After PWB/UNIX Edition 1.0 has been
installed, the old version will reside in oneqn for a while.
/usr/pub/eqnchar:
The extended mathematics symbols for neqn and eqn are avail-
able in PWB/UNIX Edition 1.0. "New Graphic Symbols for Eqn
and Neqn" by C. Scrocca tells how to access
them and use them.
mail:
The mail command has changed in PWB/UNIX Edition 1.0. It
now adds new mail entries to the end of your .mail and mbox
files. Thus "cat mbox" gives oldest-mail-first, rather than
most-recent-mail-first. To print the most recent mail
first, use:
mail -f mbox
The advantage of all this is that, if your .mail file is
mode "622" (see chmod(I)), then other people can send you
mail, but cannot read your mail.
In PWB/UNIX Edition 1.0, system-wide news is mailed to
/usr/news/.mail. Thus, use:
mail -f /usr/news/.mail
instead of:
cat /usr/unix/.mail
(In other words, that mailbox lives in /usr/news instead of
/usr/unix.)
Other features of the new mail command are:
⊕ When sending mail to someone, you can terminate the
mail with a line that has just a ".", instead of with
"Control D" (i.e., mail now resembles the "a" command
of ed).
⊕ mail with no arguments (or mail -yn) tries to use the
.mail and mbox files in your current directory. But if
.mail doesn't exist there, mail uses .mail and mbox in
your login directory instead. Thus you needn't chdir
- 3 -
PY-77-XX(PWB PIB) 5/24/77 PY-77-XX(PWB PIB)
to your login directory to read or save your mail.
⊕ You can only mail to people (i.e., login ID's), not
directories.
spell:
The PWB/UNIX Edition 1.0 spell command is greatly improved.
The new spell knows many more words. Also, if a misspelled
word has upper-case letters, the new spell reports the word
with those letters in upper-case. For example, suppose that
the first word of a sentence is misspelled -- "Theerfore".
The old spell reported the misspelling as "theerfore". The
new spell reports it as "Theerfore". As a result, the
errors are much easier to find.
Also, spell gives multi-column output (spell pipes its out-
put through the pr command). The old spell gave just a sim-
ple, one-column list. To get one-column, non-pr output from
the new spell, use:
spell -1 files ...
cat:
In PWB/UNIX Edition 1.0, if file "x" doesn't exist, the com-
mand:
cat x
gives an error message. The old cat command silently
ignored non-existent files.
echo:
The PWB/UNIX Edition 1.0 echo command prints "\" when given
"\\". Thus:
echo '\\'
will print "\"; the old echo printed "\\".
cpio, cpi-cpo:
In PWB/UNIX Edition 1.0, the cpio command replaces the old
cpi and cpo commands; see /usr/news/cpio.
The cpio intermediate file format differs from that used by
cpi-cpo. Thus old intermediate files will not work with the
new cpio.* To ease conversion, ocpio will, for a while,
accept old-format cpi-cpo intermediate files.
C compiler (cc):
The ncc that is currently available will become cc in
PWB/UNIX Edition 1.0. Also, a new conditional-compilation
________
* Furthermore, the new cpio will not work with intermediate
files created by earlier, preliminary versions of cpio.
- 4 -
PY-77-XX(PWB PIB) 5/24/77 PY-77-XX(PWB PIB)
pre-processor statement,
#if expression
has been added. The expression can only involve compile-
time constants (i.e., "#if NBLOCKS>3"). Otherwise, it is
used in the same fashion as #ifdef and #ifndef.
Portable I/O Library (-lp):
For PWB/UNIX Edition 1.0, the Portable I/O library has been
replaced by D. M. Ritchie's new "standard" I/O library
(-lS). To ease conversion, PWB/UNIX Edition 1.0 has an
"imitation" -lp library, in which the more commonly-used -lp
functions have been written in terms of the equivalent -lS
functions. The change should be transparent to most pro-
grams that use -lp, although programs that used the more
esoteric (or perverse) -lp features may not re-compile.
In any case, we strongly recommend that all programs that
use -lp be revised to use the -lS library directly.
New PWB System Calls:
Any program that calls the following functions from the -lPW
library:
logname() logtty() logdir()
pexec() uname() ustat()
must be recompiled before PWB/UNIX Edition 1.0 is installed,
unless it has been recompiled since 4/15/77. In other
words, new versions of the aforementioned functions were
installed on or before 4/15/77. Anything that was compiled
after that date is fine, but any program that has the ear-
lier versions of those functions will not work in PWB/UNIX
Edition 1.0. It will fail with an "Invalid System Call"
error.*
Furthermore, any program that calls ustat(II) may have to be
changed; the new ustat (that is, the one installed on
4/15/77) has a different argument sequence. See the new
manual page ("man 2 ustat").
pexec:
The pexec function has some new features. In particular,
the calling function can explicitly specify the list of
directories to be searched (this overrides the user's
".path" file). In addition, the ".path" file's second line,
if any, may specify the name of the program to be treated as
the Shell. See the new manual page ("man 3 pexec").
________
* I.e., the "old" PWB system calls will not exist in PWB/UNIX
Edition 1.0; only the new calls will work.
- 5 -
PY-77-XX(PWB PIB) 5/24/77 PY-77-XX(PWB PIB)
/bin, /usr/bin:
In PWB/UNIX Edition 1.0, a number of commands have migrated
from the /bin directory to the /usr/bin directory. This
includes the text-processing family -- nroff, neqn, tbl,
eqn, and troff. Also, a few commands have migrated from
/usr/bin to /bin. This shouldn't affect you, unless:
⊕ you have removed /usr/bin from your .path file (see
sh(I)), or
⊕ your Shell procedures use explicit path names for com-
mands in /bin or /usr/bin (i.e., any Shell that calls
"/bin/nroff" won't work; it must be changed to call
"/usr/bin/nroff", or, better yet, just "nroff").
crypt(I):
The PWB/UNIX Edition 1.0 crypt(I) command, which simulates a
cryptographic machine, uses a different encryption algorithm
than the old crypt. The new crypt cannot decrypt old
encrypted files. Thus any encrypted files should be
decrypted before PWB/UNIX Edition 1.0 is installed, and re-
encrypted after installation.
passwords, crypt(III):
The PWB/UNIX Edition 1.0 crypt(III) function uses a new and
more secure password encryption algorithm. A side-effect is
that the encrypted string generated by the new crypt is 11
characters long; the old crypt generated an 8 character
string.
Since login passwords are encrypted via crypt(III), this
(indirectly) affects everyone. To ease the transition,
since 5/6/77 the login procedure has been silently convert-
ing encrypted passwords from the old to the new format.*
When PWB/UNIX Edition 1.0 is installed, only new encryption
passwords will be accepted.
The moral: Anyone who hasn't logged in between 5/6/77 and
the PWB/UNIX Edition 1.0 installation date will not be able
to login after it's installed! These users will have to ask
the system administrator to set their password.
The following changes have already been installed on PWB Systems
B-F, within the last month or so. They are included here for
completeness:
SCCS:
SCCS Release 4 will be the standard for PWB/UNIX Edition
________
* To be precise, the current login(I) tries both the new and
old encryption schemes. If the old scheme matches the
/etc/passwd file entry, login automatically re-encrypts your
password using the new encryption scheme. In addition, the
current passwd(I) command uses the new encryption scheme.
- 6 -
PY-77-XX(PWB PIB) 5/24/77 PY-77-XX(PWB PIB)
1.0. The SCCS Release 3 commands will not be available in
PWB/UNIX Edition 1.0 (oadmin, oget, odelta, etc.)
rm:
In PWB/UNIX Edition 1.0, if file "x" doesn't exist, the com-
mand:
rm -f x
does not give an error message (i.e., the "-f" option
suppresses the "non-existent file" error message). The old
rm command gave an error message even if "-f" was specified.
Also, when the new rm is called from a Shell procedure, it
always assumes the "-f" option.
ed:
The PWB/UNIX Edition 1.0 ed command has a few new commands.
The j command joins lines together. ".-1,.j" tacks the
current line onto the end of the previous line, and "1,10j"
joins the first 10 lines together. A simple "j" will join
the current line and the next line. That is, "j" defaults
to ".,.+1j".
The G and V commands have also been added. They are
interactive variants of the g and v commands. They were
described in a /usr/unix/.mail entry on or about May 6, and
are fully described in ed(I) ("man 1 ed").
Shell (sh):
A number of minor improvements have been made to the Shell
and related programs.
⊕ The Shell's -x option is replaced by -v (for verbose).
⊕ Interrupt-handling has been cleaned up: ``onintr -''
causes both the current Shell procedure and the invoked
commands to be immune to interrupts. Commands invoked
asynchronously from within Shell procedures are now
immune to interrupts and quits, as they should be.
⊕ The Shell still reports the process numbers of asyn-
chronous processes created at the terminal level. It
no longer prints these numbers for asynchronous
processes created inside a Shell procedure.
⊕ The Shell variable $w gives the first component of $s,
i.e., it gives the PWB/UNIX file system name.
⊕ The Shell variable $z gives the name of the program
invoked to process Shell procedures. It is /bin/sh by
default, but is initialized from the second line of the
.path file, if there is such a line.
⊕ The switch command used to search for a label that was
identical to its argument. Now each label is con-
sidered to be a pattern (of the same form as for Shell
argument list generation) that is matched against the
switch argument. For example:
- 7 -
PY-77-XX(PWB PIB) 5/24/77 PY-77-XX(PWB PIB)
switch "$1"
: -*
cmds...
: *.c
etc...
⊕ When the `=' command reads a line from a file, it now
returns a non-zero exit code if it encountered end-of-
file on that file.
⊕ The cd command is a synonym for chdir.
⊕ ``opt -p "string"'' changes the Shell prompt string ("%
") to the argument given.
Additional copies of this PIB may be obtained from any PWB com-
puter by use of command "man pib 77 XX".
- 8 -