get(1) get(1)
NAME
get - get a version of an SCCS file
SYNOPSIS
get [-aseq-no] [-b] [-ccutoff] [-e] [-g] [-ilist] [-k]
[-l[p]] [-m] [-n] [-p] [-rSID] [-s] [-t] [-wstring] [-xlist]
file ...
DESCRIPTION
get generates an ASCII text file from each named SCCS file
according to the specifications given by its keyletter
arguments, which begin with -. The arguments may be
specified in any order, but all keyletter arguments apply to
all named SCCS files. If a directory is named, get behaves
as though each file in the directory were specified as a
named file, except that non-SCCS files (last component of
the path name does not begin with s.) and unreadable files
are silently ignored. If a name of - is given, the standard
input is read; each line of the standard input is taken to
be the name of an SCCS file to be processed. Again, non-
SCCS files and unreadable files are silently ignored.
The generated text is normally written into a file called
the g-file, the name of which is derived from the SCCS
filename simply by removing the leading s.; (see also NOTES
, below).
Each of the keyletter arguments is explained below as though
only one SCCS file is to be processed, but the effects of
any keyletter argument apply independently to each named
file.
-rSID The SCCS Identification string (SID) of the
version (delta) of an SCCS file to be retrieved.
Table 1 below shows, for the most useful cases,
what version of an SCCS file is retrieved (as
well as the SID of the version to be eventually
created by delta(1) if the -e keyletter is also
used), as a function of the SID specified.
-ccutoff cutoff date-time, in the form: YY[MM[DD[
HH[MM[SS]]]]] No changes (deltas) to the SCCS
file which were created after the specified
cutoff date-time are included in the generated
ASCII text file. Units omitted from the date-
time default to their maximum possible values;
that is, -c7502 is equivalent to -c750228235959.
Any number of non-numeric characters may separate
the various 2-digit pieces of the cutoff date-
time. This feature allows one to specify a
cutoff date in the form: -c77/2/2 9:22:25. Note
that this implies that one may use the %E% and
Page 1 (last mod. 1/16/87)
get(1) get(1)
%U% identification keywords (see below) for
nested gets within, say the input to a send(2N)
command:
~!get "-c%E% %U%" s.file
-e Indicates that the get is for the purpose of
editing or making a change (delta) to the SCCS
file via a subsequent use of delta(1). The -e
keyletter used in a get for a particular version
(SID) of the SCCS file prevents further gets for
editing on the same SID until delta is executed
or the j (joint edit) flag is set in the SCCS
file (see admin(1)). Concurrent use of get -e
for different SIDs is always allowed.
If the g-file generated by get with an -e
keyletter is accidentally ruined in the process
of editing it, it may be regenerated by re-
executing the get command with the -k keyletter
in place of the -e keyletter.
SCCS file protection specified via the ceiling,
floor, and authorized user list stored in the
SCCS file (see admin(1)) are enforced when the -e
keyletter is used.
-b Used with the -e keyletter to indicate that the
new delta should have an SID in a new branch as
shown in Table 1. This keyletter is ignored if
the b flag is not present in the file (see
admin(1)) or if the retrieved delta is not a leaf
delta. (A leaf delta is one that has no
successors on the SCCS file tree.) A branch delta
may always be created from a non-leaf delta.
-ilist A list of deltas to be included (forced to be
applied) in the creation of the generated file.
The list has the following syntax:
<list> ::= <range> | <list> , <range>
<range> ::= SID | SID-SID
SID, the SCCS Identification of a delta, may be
in any form shown in the ``SID Specified'' column
of Table 1. Partial SIDs are interpreted as
shown in the ``SID Retrieved'' column of Table 1.
-xlist A list of deltas to be excluded (forced not to be
applied) in the creation of the generated file.
See the -i keyletter for the list format.
-k Suppresses replacement of identification keywords
Page 2 (last mod. 1/16/87)
get(1) get(1)
(see below) in the retrieved text by their value.
The -k keyletter is implied by the -e keyletter.
-l[p] Causes a delta summary to be written into an l-
file. If -lp is used, then an l-file is not
created; the delta summary is written on the
standard output instead. See NOTES for the
format of the l-file.
-p Causes the text retrieved from the SCCS file to
be written on the standard output. No g-file is
created. All output which normally goes to the
standard output goes to file descriptor 2
instead, unless the -s keyletter is used, in
which case it disappears.
-s Suppresses all output normally written on the
standard output. However, fatal error messages
(which always go to file descriptor 2) remain
unaffected.
-m Causes each text line retrieved from the SCCS
file to be preceded by the SID of the delta that
inserted the text line in the SCCS file. The
format is: SID, followed by a horizontal tab,
followed by the text line.
-n Causes each generated text line to be preceded
with the %M% identification keyword value (see
below). The format is: %M%value, followed by a
horizontal tab, followed by the text line. When
both the -m and -n keyletters are used, the
format is: %M%value, followed by a horizontal
tab, followed by the -m keyletter generated
format.
-g Suppresses the actual retrieval of text from the
SCCS file. It is primarily used to generate an
l-file, or to verify the existence of a
particular SID.
-t Used to access the most recently created (top)
delta in a given release (e.g., -r1), or release
and level (e.g., -r1.2).
-wstring Substitute string for all occurrences of %W% when
running get on the file.
-aseq-no The delta sequence number of the SCCS file delta
(version) to be retrieved (see sccsfile(5)).
This keyletter is used by the comb(1) command; it
is not a generally useful keyletter, and users
Page 3 (last mod. 1/16/87)
get(1) get(1)
should not use it. If both the -r and -a
keyletters are specified, the -a keyletter is
used. Care should be taken when using the -a
keyletter in conjunction with the -e keyletter,
as the SID of the delta to be created may not be
what one expects. The -r keyletter can be used
with the -a and -e keyletters to control the
naming of the SID of the delta to be created.
For each file processed, get responds (on the standard
output) with the SID being accessed and with the number of
lines retrieved from the SCCS file.
If the -e keyletter is used, the SID of the delta to be made
appears after the SID accessed and before the number of
lines generated. If there is more than one named file or if
a directory or standard input is named, each filename is
printed (preceded by a newline) before it is processed. If
the -i keyletter is used included deltas are listed
following the notation Included; if the -x keyletter is
used, excluded deltas are listed following the notation
Excluded.
Page 4 (last mod. 1/16/87)
get(1) get(1)
TABLE 1. Determination of SCCS Identification String
_________________________________________________________________
SID* -b Keyletter Other SID SID of Delta
Specified Used† Conditions Retrieved to be Created
_________________________________________________________________
none‡ no R defaults to mR mR.mL mR.(mL+1)
_________________________________________________________________
none‡ yes R defaults to mR mR.mL mR.mL.(mB+1).1
_________________________________________________________________
R no R > mR mR.mL R.1***
_________________________________________________________________
R no R = mR mR.mL mR.(mL+1)
_________________________________________________________________
R yes R > mR mR.mL mR.mL.(mB+1).1
_________________________________________________________________
R yes R = mR mR.mL mR.mL.(mB+1).1
_________________________________________________________________
R < mR and
R - R does not exist hR.mL** hR.mL.(mB+1).1
_________________________________________________________________
Trunk succ.#
R - in release > R R.mL R.mL.(mB+1).1
and R exists
_________________________________________________________________
R.L no No trunk succ. R.L R.(L+1)
_________________________________________________________________
R.L yes No trunk succ. R.L R.L.(mB+1).1
_________________________________________________________________
Trunk succ.
R.L - in release > R R.L R.L.(mB+1).1
_________________________________________________________________
R.L.B no No branch succ. R.L.B.mS R.L.B.(mS+1)
_________________________________________________________________
R.L.B yes No branch succ. R.L.B.mS R.L.(mB+1).1
_________________________________________________________________
R.L.B.S no No branch succ. R.L.B.S R.L.B.(S+1)
_________________________________________________________________
R.L.B.S yes No branch succ. R.L.B.S R.L.(mB+1).1
_________________________________________________________________
R.L.B.S - Branch succ. R.L.B.S R.L.(mB+1).1
_________________________________________________________________
* R, L, B, and S are the release, level, branch, and
sequence components of the SID , respectively; `m'
means maximum. Thus, for example, R.mL means the
maximum level number within release R;
``R.L.(mB+1).1'' means the first sequence number on
the new branch (i.e., maximum branch number plus
one) of level L within release R. Note that if the
SID specified is of the form R.L, R.L.B, or
R.L.B.S, each of the specified components must
exist.
Page 5 (last mod. 1/16/87)
get(1) get(1)
** ``hR'' is the highest existing release that is lower
than the specified, nonexistent, release R.
*** This is used to force creation of the first delta in
a new release.
# Successor.
† The -b keyletter is effective only if the b flag
(see admin(1)) is present in the file. An entry of
- means irrelevant.
‡ This case applies if the d (default SID) flag is not
present in the file. If the d flag is present in
the file, then the SID obtained from the d flag is
interpreted as if it had been specified on the
command line. Thus, one of the other cases in this
table applies.
IDENTIFICATION KEYWORDS
Identifying information is inserted into the text retrieved
from the SCCS file by replacing identification keywords with
their value wherever they occur. The following keywords may
be used in the text stored in an SCCS file:
Keyword Value
%M% Module name: either the value of the m flag in the
file (see admin(1)), or if absent, the name of the
SCCS file with the leading s. removed.
%I% SCCS identification (SID) (%R%.%L%.%B%.%S%) of the
retrieved text.
%R% Release.
%L% Level.
%B% Branch.
%S% Sequence.
%D% Current date (YY/MM/DD).
%H% Current date (MM/DD/YY).
%T% Current time (HH:MM:SS).
%E% Date newest applied delta was created
(YY/MM/DD\fR).
%G% Date newest applied delta was created (MM/DD/YY).
%U% Time newest applied delta was created (HH:MM:SS).
%Y% Module type: value of the t flag in the SCCS file
(see admin(1)).
%F% SCCS filename.
%P% Fully qualified SCCS filename.
%Q% The value of the q flag in the file (see admin(1)).
%C% Current line number. This keyword is intended for
identifying messages output by the program such as
this should not have happened type errors. It is
not intended to be used on every line to provide
sequence numbers.
%Z% The 4-character string @(#) recognizable by
what(1).
%W% A shorthand notation for constructing what(1)
strings for Oreo system program files.
Page 6 (last mod. 1/16/87)
get(1) get(1)
%W%=%Z%%M%<horizontal-tab>%I%
%A% Another shorthand notation for constructing what(1)
strings for non-Oreo system program files.
%A%=%Z%%Y%%M%%I%%Z%
EXAMPLE
get -e s.file1
generates from the SCCS format file, s.file1, the text file,
file1, for editing.
NOTES
Several auxiliary files may be created by get. These files
are known generically as the g-file, l-file, p-file, and z-
file. The letter before the hyphen is called the tag. An
auxiliary filename is formed from the SCCS filename: the
last component of all SCCS filenames must be of the form
s.module-name, the auxiliary files are named by replacing
the leading s with the tag. The g-file is an exception to
this scheme: the g-file is named by removing the s. prefix.
For example, s.xyz.c, the auxiliary filenames would be
xyz.c, l.xyz.c, p.xyz.c, and z.xyz.c, respectively.
The g-file, which contains the generated text, is created in
the current directory (unless the -p keyletter is used). A
g-file is created in all cases, whether or not any lines of
text were generated by the get. It is owned by the real
user. If the -k keyletter is used or implied its mode is
644; otherwise, its mode is 444. Only the real user need
have write permission in the current directory.
The l-file contains a table showing which deltas were
applied in generating the retrieved text. The l-file is
created in the current directory if the -l keyletter is
used; its mode is 444 and it is owned by the real user.
Only the real user need have write permission in the current
directory.
Lines in the l-file have the following format:
a. A blank character if the delta was applied;
* otherwise.
b. A blank character if the delta was applied or was not
applied and ignored;
* if the delta was not applied and was not ignored.
c. A code indicating a special reason why the delta was
or was not applied:
I: Included.
X: Excluded.
C: Cut off (by a -c keyletter).
d. Blank.
e. SCCS identification (SID).
Page 7 (last mod. 1/16/87)
get(1) get(1)
f. TAB character.
g. Date and time (in the form YY/MM/DD HH:MM:SS) of
creation.
h. Blank.
i. Login name of person who created delta.
The comments and MR data follow on subsequent lines,
indented one horizontal tab character. A blank line
terminates each entry.
The p-file is used to pass information resulting from a get
with an -e keyletter along to delta. Its contents are also
used to prevent a subsequent execution of get with an -e
keyletter for the same SID until delta is executed or the
joint edit flag, j, (see admin(1)) is set in the SCCS file.
The p-file is created in the directory containing the SCCS
file and the effective user must have write permission in
that directory. Its mode is 644 and it is owned by the
effective user. The format of the p-file is: the gotten
SID, followed by a blank, followed by the SID that the new
delta will have when it is made, followed by a blank,
followed by the login name of the real user, followed by a
blank, followed by the date-time the get was executed,
followed by a blank and the -i keyletter argument if it was
present, followed by a blank and the -x keyletter argument
if it was present, followed by a newline. There can be an
arbitrary number of lines in the p-file at any time; no two
lines can have the same new delta SID.
The z-file serves as a lock-out mechanism against
simultaneous updates. Its contents are the binary (2 bytes)
process ID of the command (i.e., get) that created it. The
z-file is created in the directory containing the SCCS file
for the duration of get. The same protection restrictions
as those for the p-file apply for the z-file. The z-file is
created mode 444.
FILES
/usr/bin/get
SEE ALSO
admin(1), delta(1), help(1), prs(1), what(1), sccsfile(4).
``SCCS Reference'' in Oreo Programming Languages and Tools,
Volume 2.
DIAGNOSTICS
Use help(1) for explanations.
BUGS
If the effective user has write permission (either
explicitly or implicitly) in the directory containing the
SCCS files, but the real user does not, then only one file
Page 8 (last mod. 1/16/87)
get(1) get(1)
may be named when the -e keyletter is used.
Page 9 (last mod. 1/16/87)