®les are named by replacing the leading s with the tag. The g-®leis an exception to this scheme: the g-®leis named by removing the s. pre®x. For example, s.xyz.c, the auxiliary ®le names would be xyz.c, l.xyz.c, p.xyz.c, and z.xyz.c, respectively.
The g-®le, which contains the generated text, is created in the current directory (unless the -poption is used). A g-®leis 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 -koption 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-®lecontains a table showing which deltas were applied in generating the retrieved text. The l-®leis created in the current directory if the -loption 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-®lehave the following format:
1.A blank character if the delta was applied;
*otherwise.
2.A blank character if the delta was applied or was not applied and ignored;
*if the delta was not applied and was not ignored.
3.A code indicating a "special" reason why the delta was or was not applied:
I: Included.
X: Excluded.
C: Cut off (by a -coption).
4.Blank.
5.SCCS identi®cation (SID).
6.Tab character.
7.Creation date and time (in the form YY/MM/DD HH:MM:SS).
8.Blank.
9.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-®leis used to pass information resulting from a get with an -eoption along to delta. Its contents are also used to prevent a subsequent execution of get with an -eoption for the same SID until delta is executed or the joint edit ¯ag, j, (see admin(1)) is set in the SCCS ®le. The p-®leis created in the directory containing the SCCS ®le 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-®leis: 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 -ioption argument if it was present, followed by a blank and the -xoption argument if it was present, followed by a new-line. There can be an arbitrary number of lines in the p-®leat any time; no two lines can have the same new delta SID.
The z-®leserves as a lock-outmechanism against simultaneous updates. Its contents are the binary (2 bytes) process ID of the command (i.e., get) that created it. The z-®leis created in the directory containing the SCCS ®le for the duration of get. The same protection restrictions as those for the p-®leapply for the z-®le. The z-®leis created mode 444.
SEE ALSO
admin(1), delta(1), prs(1), sccshelp(1), what(1), sccs®le(4).
STANDARDS CONFORMANCE
get: SVID2, SVID3, XPG2, XPG3, XPG4
