Command Reference Guide
__________________________________________________________________________________________________________________________________________________________________________________________________
__________________________________________________________________________________________________________________________________________________________________________________________________
STANDARD Printed by: Nora Chuang [nchuang] STANDARD
/build/1111/BRICK/man1/!!!intro.1
________________________________________________________________
___ ___
g
get(1) get(1)
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 file names 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 option is
used). A g-file is created in all cases, whether or not any lines of text were generated by the get.Itis
owned by the real user. If the -k option 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 option 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:
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 indicatinga "special" reason why the delta was or was not applied:
I: Included.
X: Excluded.
C: Cut off (by a -c option).
4. Blank.
5. SCCS identification (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-file is used to pass information resulting from a
get with an -e
option along to delta. Its contents
are also used to prevent a subsequent execution of
get with an -e option 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 direc-
tory 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 option argument if it was present, followed by a blank and the -x option argument if it
was present, followed by a new-line. 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 contain-
ing 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.
SEE ALSO
admin(1), delta(1), prs(1), sccshelp(1), what(1), sccsfile(4).
STANDARDS CONFORMANCE
get: SVID2, SVID3, XPG2, XPG3, XPG4
Section 1−−322 − 5 − HP-UX Release 11i: December 2000
___
___