Путеводитель по Руководству Linux

  User  |  Syst  |  Libr  |  Device  |  Files  |  Other  |  Admin  |  Head  |



   get.1p    ( 1 )

получить версию файла SCCS (РАЗРАБОТКА) (get a version of an SCCS file (DEVELOPMENT))

Выходные файлы (Output files)

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.