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-minus> is called the tag. An auxiliary
filename shall be formed from the SCCS filename: the application
shall ensure that the last component of all SCCS filenames is of
the form s.module-name; the auxiliary files shall be named by
replacing the leading s with the tag. The g-file shall be an
exception to this scheme: the g-file is named by removing the s.
prefix. For example, for 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, shall be created
in the current directory (unless the -p option is used). A g-file
shall be created in all cases, whether or not any lines of text
were generated by the get. It shall be owned by the real user.
If the -k option is used or implied, the g-file shall be writable
by the owner only (read-only for everyone else); otherwise, it
shall be read-only. Only the real user need have write permission
in the current directory.
The l-file shall contain a table showing which deltas were
applied in generating the retrieved text. The l-file shall be
created in the current directory if the -l option is used; it
shall be read-only 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 shall have the following format:
"%c%c%c %s\t%s %s\n", <code1>, <code2>, <code3>,
<SID>, <date-time>, <login>
where the entries are:
<code1> A <space> if the delta was applied; '*' otherwise.
<code2> A <space> if the delta was applied or was not applied
and ignored; '*' if the delta was not applied and was
not ignored.
<code3> A character indicating a special reason why the delta
was or was not applied:
I Included.
X Excluded.
C Cut off (by a -c option).
<date-time>
Date and time (using the format of the date utility's
%y/%m/%d %T conversion specification format) of
creation.
<login> Login name of person who created delta.
The comments and MR data shall follow on subsequent lines,
indented one <tab>. A blank line shall terminate each entry.
The p-file shall be used to pass information resulting from a get
with a -e option along to delta. Its contents shall also be used
to prevent a subsequent execution of get with a -e option for the
same SID until delta is executed or the joint edit flag, j, is
set in the SCCS file. The p-file shall be created in the
directory containing the SCCS file and the application shall
ensure that the effective user has write permission in that
directory. It shall be writable by owner only, and owned by the
effective user. Each line in the p-file shall have the following
format:
"%s %s %s %s%s%s\n", <g-file SID>,
<SID of new delta>, <login-name of real user>,
<date-time>, <i-value>, <x-value>
where <i‐value> uses the format "" if no -i option was specified,
and shall use the format:
" -i%s", <-i option option-argument>
if a -i option was specified and <x‐value> uses the format "" if
no -x option was specified, and shall use the format:
" -x%s", <-x option option-argument>
if a -x option was specified. There can be an arbitrary number of
lines in the p-file at any time; no two lines shall have the same
new delta SID.
The z-file shall serve as a lock-out mechanism against
simultaneous updates. Its contents shall be the binary process ID
of the command (that is, get) that created it. The z-file shall
be created in the directory containing the SCCS file for the
duration of get. The same protection restrictions as those for
the p-file shall apply for the z-file. The z-file shall be
created read-only.
