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 _a_d_m_i_n, _g_e_t, _p_r_t, and _d_e_l_t_a.
User documentation for the release 4.0 commands is available
under the _m_a_n(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. _M_A_J_O_R__I_N_C_O_M_P_A_T_I_B_I_L_I_T_I_E_S
1.1 _F_i_l_e__F_o_r_m_a_t__a_n_d__P_r_t
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 _s_c_c_s_f_i_l_e(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, _g_r_e_p/_s_e_d 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 _g_r_e_p or
_s_e_d 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 _e_d(I). Finally, the _c_a_t(I) command can be used
to "dump" an SCCS file.
Due to the change in file format, the output format of the
_p_r_t(I) command has changed drastically; see _p_r_t(I).
- 1 -
PY-77-05(PWB PIB) 2/22/77 PY-77-05(PWB PIB)
1.2 _N_o_n_-_p_r_o_p_a_g_a_t_i_n_g__D_e_l_t_a_s
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 _g_e_t command which
provides for upward compatibility of the defaults for SIDs. The
-_t keyletter on _g_e_t 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
_S_I_D _s_p_e_c_i_f_i_e_d _S_I_D _a_c_t_u_a_l_l_y _g_o_t_t_e_n _n_e_w _S_I_D (_i_f _g_e_t -_e) _N_o_t_e_s
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
_S_I_D _s_p_e_c_i_f_i_e_d _S_I_D _a_c_t_u_a_l_l_y _g_o_t_t_e_n _n_e_w _S_I_D (_i_f _g_e_t -_e) _N_o_t_e_s
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
_N_o_t_e_s
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). _T_h_i_s _l_a_s_t _c_o_n_d_i_t_i_o_n _i_s _n_o_t _u_p_w_a_r_d
_c_o_m_p_a_t_i_b_l_e _w_i_t_h _r_e_l_e_a_s_e _3 _S_C_C_S/_P_W_B.
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. _T_h_i_s
_s_i_t_u_a_t_i_o_n _i_s _n_o_t _u_p_w_a_r_d _c_o_m_p_a_t_i_b_l_e _w_i_t_h _r_e_l_e_a_s_e _3 _S_C_C_S/_P_W_B.
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 _i_s 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. _F_E_A_T_U_R_E_S__N_O__L_O_N_G_E_R__S_U_P_P_O_R_T_E_D
Besides what was mentioned above, the following are no longer
supported:
2.1 _A_d_m_i_n
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 _P_r_t
As described above, because of the change in the SCCS file for-
mat, the output format of _p_r_t(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 _G_e_t
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 _D_e_l_t_a
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. _F_E_A_T_U_R_E_S__T_H_A_T__H_A_V_E__C_H_A_N_G_E_D
3.1 _A_d_m_i_n
1. The _t_y_p_e, _f_l_o_o_r, and _c_e_i_l_i_n_g 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 _a_d_m_i_n
simply zeroed the checksum).
3.2 _P_r_t
The format of the delta table and the body have changed, and the
meaning of the _s keyletter has changed; see _p_r_t(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 _G_e_t
1. The value of an _r keyletter argument is now an SID. See
above or _g_e_t(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 _g_e_t commands within _s_e_n_d(I) input; see
_g_e_t(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-_f_i_l_e has changed drastically; see
_g_e_t(I).
5. The format of the _m keyletter output is: SID, followed by a
horizontal tab, followed by the text line. The
_r_e_f_o_r_m(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-_f_i_l_e 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-_f_i_l_e 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 _w_h_a_t(I) command
has already been changed to recognize both the old %Z%
replacement and the new %Z% replacement.
11. The format of the _p-_f_i_l_e has changed drastically; see
_g_e_t(I).
3.4 _D_e_l_t_a
The prompt for "history? " has been changed to a prompt for "com-
ments? ". Also, if there is a _v flag in the file, _d_e_l_t_a 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 _d_e_l_t_a(I).
4. _N_E_W__F_E_A_T_U_R_E_S
4.1 _I_m_p_r_o_v_e_d__E_r_r_o_r__H_a_n_d_l_i_n_g
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 _C_h_e_c_k_i_n_g__f_o_r__C_o_r_r_u_p_t_e_d__S_C_C_S__F_i_l_e_s
The _h keyletter on the _a_d_m_i_n(I) command causes _a_d_m_i_n to
check the stored checksum against a computed checksum. _A_d_m_i_n 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 _F_l_a_g_s
There are seven flags in release 4 SCCS files. All may be set,
removed, or changed with _a_d_m_i_n(I). See _a_d_m_i_n(I) for
the meanings of the different flags.
4.4 _U_s_e_r__T_e_x_t
A portion of an SCCS file is reserved for arbitrary text supplied
by the user. This text is changed with the _a_d_m_i_n(I) com-
mand. This portion of the file is intended to take the place of
the release 3 description and person fields.
4.5 _P_r_t
_P_r_t(I) has new keyletter arguments to print the new pieces
of an SCCS file; see _p_r_t(I).
4.6 _G_e_t
4.6.1 _M_u_l_t_i_p_l_e _G_e_t -_e _C_o_m_m_a_n_d_s It is possible for more than one
get-edit-delta sequence to be active at the same time, provided
that no two _g_e_t_s 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
_g_e_t for the file in question will be terminated. A warning will
be produced whenever another user has already done a (non-
interfering) _g_e_t -_e. The format of the _p-_f_i_l_e has changed drast-
ically as a result of this new feature; see _g_e_t(I). If the
same user has done more than one _g_e_t -_e then that user must use
the -_r keyletter on _d_e_l_t_a until there is no ambiguity about which
delta is to be made; see _d_e_l_t_a(I).
4.6.2 -_b _k_e_y_l_e_t_t_e_r 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 _a_d_m_i_n(I).
4.6.3 -_g _k_e_y_l_e_t_t_e_r The -_g keyletter suppresses the actual get-
ting of source. It may be used to retrieve an _l-_f_i_l_e, 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 _k_e_y_l_e_t_t_e_r 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 _I_n_c_l_u_d_e/_E_x_c_l_u_d_e In release 4, the -_i and the -_x arguments
are recorded in the _p-_f_i_l_e and are used when making the delta
(i.e., when _d_e_l_t_a regenerates the _g-_f_i_l_e 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-_f_i_l_e). 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), _g_e_t 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-_f_i_l_e.
4.7 _D_e_l_t_a
_D_e_l_t_a will use the _d_i_f_f(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-_f_i_l_e. 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 _i_s 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 _L_o_c_k_o_u_t
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-_f_i_l_e.
5. _C_O_N_V_E_R_S_I_O_N__F_R_O_M__R_E_L_E_A_S_E__3__T_O__R_E_L_E_A_S_E__4
Release 3 files are converted to release 4 files by executing the
command:
_s_c_v name ...
where "name" is any file name argument acceptable to the release
3 _g_e_t command (including directory names, or a name of "-"). The
_s_c_v command prints the name of each file processed. After a file
has been processed, the release 3 file is _r_e_p_l_a_c_e_d 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 _l_n(I)) or a copy (see _c_p(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-_f_i_l_e_s are _n_o_t acceptable to release 4 commands.
Therefore, either (release 3) _d_e_l_t_a should be executed before
_s_c_v, or the _p-_f_i_l_e should be removed. _S_c_v will not convert a
release 3 SCCS file if there is a _p-_f_i_l_e 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 _s_c_v, 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 _a_d_m_i_n(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 ..."
- _W_e_s_t _S_i_d_e _S_t_o_r_y
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 _n_o_t 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 _k_n_o_w_n differences:
_P_W_B/_M_M _M_a_c_r_o_s:
PWB/UNIX Edition 1.0 has a new version of the Memorandum
Macros. The _n_r_o_f_f output of PWB/MM moves closer to the
_t_r_o_f_f output appearance.* The new default _n_r_o_f_f appearance
incorporates the following:
o+ 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.
o+ The text for all heading levels will be underlined.
________
* In fact, the new _n_r_o_f_f version of PWB/MM is based on the
existing _t_r_o_f_f version.
- 1 -
PY-77-XX(PWB PIB) 5/24/77 PY-77-XX(PWB PIB)
o+ The indentation for dash lists and bullet lists is the
same as for the paragraph indentation. Previously,
these lists were indented two spaces.
o+ .SA 0 (no right adjustment) is the default for _n_r_o_f_f.
_n_r_o_f_f:
PWB/UNIX Edition 1.0 has a new ("C") version of _n_r_o_f_f. It
is vastly different from the previous (assembler) version.
The _n_r_o_f_f ``language'' is now closer to _t_r_o_f_f than before.
In fact, both _n_r_o_f_f and _t_r_o_f_f 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 _n_r_o_f_f.
After PWB/UNIX Edition 1.0 has been installed, the old ver-
sion of _n_r_o_f_f will reside in _o_n_r_o_f_f for a period of time.
_t_b_l:
The PWB/UNIX Edition 1.0 version of the program to set
tables of data, _t_b_l, 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 _m_u_s_t be converted. The program
_c_v_t_b_l will do this conversion. For example:
cvtbl file...
will convert the column specifications in the given file(s).
The _t_b_l manual mentions certain features that are functions of
the -ms macro package,* and _n_o_t of _t_b_l itself:
o+ The .TC synonym for .T& must _n_o_t be used. It conflicts
with the .TC macro of PWB/MM.
o+ The .T# and .TH macros are not yet implemented in
PWB/MM. Thus, multi-page boxed tables cannot be done.
The new _t_b_l works only with the new _n_r_o_f_f and _t_r_o_f_f. That
is, new _t_b_l is _n_o_t compatible with _o_n_r_o_f_f. 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 _t_b_l will
reside in _o_t_b_l for a brief period.
_n_e_q_n:
The PWB/UNIX Edition 1.0 _n_e_q_n has been revised to use the
features of the new _n_r_o_f_f. 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 _n_e_q_n cannot
work with _o_n_r_o_f_f. After PWB/UNIX Edition 1.0 has been
installed, the old version will reside in _o_n_e_q_n for a while.
/_u_s_r/_p_u_b/_e_q_n_c_h_a_r:
The extended mathematics symbols for _n_e_q_n and _e_q_n 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.
_m_a_i_l:
The _m_a_i_l command has changed in PWB/UNIX Edition 1.0. It
now adds new mail entries to the _e_n_d of your ._m_a_i_l and _m_b_o_x
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 ._m_a_i_l file is
mode "622" (see _c_h_m_o_d(I)), then other people can send you
mail, but cannot _r_e_a_d your mail.
In PWB/UNIX Edition 1.0, system-wide news is mailed to
/_u_s_r/_n_e_w_s/._m_a_i_l. Thus, use:
mail -f /usr/news/.mail
instead of:
cat /usr/unix/.mail
(In other words, that mailbox lives in /_u_s_r/_n_e_w_s instead of
/_u_s_r/_u_n_i_x.)
Other features of the new _m_a_i_l command are:
o+ When sending mail to someone, you can terminate the
mail with a line that has just a ".", instead of with
"Control D" (i.e., _m_a_i_l now resembles the "a" command
of _e_d).
o+ _m_a_i_l with no arguments (or _m_a_i_l -_y_n) tries to use the
._m_a_i_l and _m_b_o_x files in your current directory. But if
._m_a_i_l doesn't exist there, _m_a_i_l uses ._m_a_i_l and _m_b_o_x in
your login directory instead. Thus you needn't _c_h_d_i_r
- 3 -
PY-77-XX(PWB PIB) 5/24/77 PY-77-XX(PWB PIB)
to your login directory to read or save your mail.
o+ You can only _m_a_i_l to people (i.e., login ID's), not
directories.
_s_p_e_l_l:
The PWB/UNIX Edition 1.0 _s_p_e_l_l command is greatly improved.
The new _s_p_e_l_l knows many more words. Also, if a misspelled
word has upper-case letters, the new _s_p_e_l_l reports the word
with those letters in upper-case. For example, suppose that
the first word of a sentence is misspelled -- "Theerfore".
The old _s_p_e_l_l reported the misspelling as "theerfore". The
new _s_p_e_l_l reports it as "Theerfore". As a result, the
errors are much easier to find.
Also, _s_p_e_l_l gives multi-column output (_s_p_e_l_l pipes its out-
put through the _p_r command). The old _s_p_e_l_l gave just a sim-
ple, one-column list. To get one-column, non-_p_r output from
the new _s_p_e_l_l, use:
spell -1 files ...
_c_a_t:
In PWB/UNIX Edition 1.0, if file "x" doesn't exist, the com-
mand:
cat x
gives an error message. The old _c_a_t command silently
ignored non-existent files.
_e_c_h_o:
The PWB/UNIX Edition 1.0 _e_c_h_o command prints "\" when given
"\\". Thus:
echo '\\'
will print "\"; the old _e_c_h_o printed "\\".
_c_p_i_o, _c_p_i-_c_p_o:
In PWB/UNIX Edition 1.0, the _c_p_i_o command replaces the old
_c_p_i and _c_p_o commands; see /_u_s_r/_n_e_w_s/_c_p_i_o.
The _c_p_i_o intermediate file format differs from that used by
_c_p_i-_c_p_o. Thus old intermediate files _w_i_l_l _n_o_t _w_o_r_k with the
new _c_p_i_o.* To ease conversion, _o_c_p_i_o will, for a while,
accept old-format _c_p_i-_c_p_o intermediate files.
_C _c_o_m_p_i_l_e_r (_c_c):
The _n_c_c that is currently available will become _c_c in
PWB/UNIX Edition 1.0. Also, a new conditional-compilation
________
* Furthermore, the new _c_p_i_o will not work with intermediate
files created by earlier, preliminary versions of _c_p_i_o.
- 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.
_P_o_r_t_a_b_l_e _I/_O _L_i_b_r_a_r_y (-_l_p):
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 _s_t_r_o_n_g_l_y recommend that all programs that
use -lp be revised to use the -lS library directly.
_N_e_w _P_W_B _S_y_s_t_e_m _C_a_l_l_s:
Any program that calls the following functions from the -lPW
library:
logname() logtty() logdir()
pexec() uname() ustat()
_m_u_s_t 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 _u_s_t_a_t(II) may have to be
changed; the new _u_s_t_a_t (that is, the one installed on
4/15/77) has a different argument sequence. See the new
manual page ("man 2 ustat").
_p_e_x_e_c:
The _p_e_x_e_c 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)
/_b_i_n, /_u_s_r/_b_i_n:
In PWB/UNIX Edition 1.0, a number of commands have migrated
from the /_b_i_n directory to the /_u_s_r/_b_i_n directory. This
includes the text-processing family -- _n_r_o_f_f, _n_e_q_n, _t_b_l,
_e_q_n, and _t_r_o_f_f. Also, a few commands have migrated from
/_u_s_r/_b_i_n to /_b_i_n. This shouldn't affect you, unless:
o+ you have removed /_u_s_r/_b_i_n from your ._p_a_t_h file (see
_s_h(I)), or
o+ your Shell procedures use explicit path names for com-
mands in /_b_i_n or /_u_s_r/_b_i_n (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").
_c_r_y_p_t(I):
The PWB/UNIX Edition 1.0 _c_r_y_p_t(I) command, which simulates a
cryptographic machine, uses a different encryption algorithm
than the old _c_r_y_p_t. The new _c_r_y_p_t _c_a_n_n_o_t decrypt old
encrypted files. Thus any encrypted files should be
decrypted before PWB/UNIX Edition 1.0 is installed, and re-
encrypted after installation.
_p_a_s_s_w_o_r_d_s, _c_r_y_p_t(III):
The PWB/UNIX Edition 1.0 _c_r_y_p_t(III) function uses a new and
more secure password encryption algorithm. A side-effect is
that the encrypted string generated by the new _c_r_y_p_t is 11
characters long; the old _c_r_y_p_t generated an 8 character
string.
Since login passwords are encrypted via _c_r_y_p_t(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.
_T_h_e _m_o_r_a_l: Anyone who hasn't logged in between 5/6/77 and
the PWB/UNIX Edition 1.0 installation date will _n_o_t 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:
_S_C_C_S:
SCCS Release 4 will be the standard for PWB/UNIX Edition
________
* To be precise, the current _l_o_g_i_n(I) tries both the new and
old encryption schemes. If the _o_l_d scheme matches the
/etc/passwd file entry, _l_o_g_i_n automatically re-encrypts your
password using the _n_e_w encryption scheme. In addition, the
current _p_a_s_s_w_d(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 _n_o_t be available in
PWB/UNIX Edition 1.0 (_o_a_d_m_i_n, _o_g_e_t, _o_d_e_l_t_a, etc.)
_r_m:
In PWB/UNIX Edition 1.0, if file "x" doesn't exist, the com-
mand:
rm -f x
does _n_o_t give an error message (i.e., the "-f" option
suppresses the "non-existent file" error message). The old
_r_m command gave an error message even if "-f" was specified.
Also, when the new _r_m is called from a Shell procedure, it
always assumes the "-f" option.
_e_d:
The PWB/UNIX Edition 1.0 _e_d 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 _n_e_x_t 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 /_u_s_r/_u_n_i_x/._m_a_i_l entry on or about May 6, and
are fully described in _e_d(I) ("man 1 ed").
_S_h_e_l_l (_s_h):
A number of minor improvements have been made to the Shell
and related programs.
o+ The Shell's -x option is replaced by -v (for verbose).
o+ 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.
o+ 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.
o+ The Shell variable $w gives the first component of $s,
i.e., it gives the PWB/UNIX file system name.
o+ The Shell variable $z gives the name of the program
invoked to process Shell procedures. It is /_b_i_n/_s_h by
default, but is initialized from the second line of the
._p_a_t_h file, if there is such a line.
o+ The _s_w_i_t_c_h 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
_s_w_i_t_c_h argument. For example:
- 7 -
PY-77-XX(PWB PIB) 5/24/77 PY-77-XX(PWB PIB)
switch "$1"
: -*
cmds...
: *.c
etc...
o+ 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.
o+ The _c_d command is a synonym for _c_h_d_i_r.
o+ ``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 -