admin man page on IRIX

Man page or keyword search:  
man Server   31559 pages
apropos Keyword Search (all sections)
Output format
IRIX logo
[printable version]



admin(1)							      admin(1)

NAME
     admin - create and administer SCCS files

SYNOPSIS
     admin [-n] [-i[name]] [-r rel] [-t[name]] [-f flag[flag-val]][-d flag[flag-val]] [-a login] [-e login] [-m mrlist] [-y[comment]] [-h] [-z] files

DESCRIPTION
     admin is used to create new SCCS files and change parameters of existing
     ones.  Arguments to admin, which may appear in any order, consist of
     keyletter arguments, which begin with -, and named files (note that SCCS
     filenames must begin with the characters s.).  If a named file does not
     exist, it is created and its parameters are initialized according to the
     specified keyletter arguments.  Parameters not initialized by a keyletter
     argument are assigned a default value.  If a named file does exist,
     parameters corresponding to specified keyletter arguments are changed and
     other parameters are left as is.

     If a directory is named, admin behaves as though each file in the
     directory were specified as a named file, except that non-SCCS files
     (last component of the pathname 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.

OPTIONS
     The keyletter arguments are as follows.  Each is explained as though only
     one named file is to be processed because the effects of the arguments
     apply independently to each named file.

	  -n		 This keyletter indicates that a new SCCS file is to
			 be created.

	  -i[name]	 The name of a file from which the text for a new SCCS
			 file is to be taken.  The text constitutes the first
			 delta of the file (see -r keyletter for delta
			 numbering scheme).  If the i keyletter is used but
			 the filename is omitted, the text is obtained by
			 reading the standard input until an end of Rused,file
			 is encountered.  If this keyletter is omitted, then
			 the SCCS file is created empty.  Only one SCCS file
			 may be created by an admin command on which the i
			 keyletter is supplied.	 Using a single admin to
			 create two or more SCCS files requires that they be
			 created empty (no -i keyletter).  Note that the -i
			 keyletter implies the -n keyletter.

	  -rrel		 The release into which the initial delta is inserted.
			 If the -r keyletter is not used, the initial delta is
			 inserted into release 1.  The level of the initial
			 delta is always 1 (by default initial deltas are
			 named 1.1).

									Page 1

admin(1)							      admin(1)

	  -t[name]	 The name of a file from which descriptive text for
			 the SCCS file is to be taken.	If the -t keyletter is
			 used and admin is creating a new SCCS file (the -n
			 and/or -i keyletters also used), the descriptive text
			 filename must also be supplied.  In the case of
			 existing SCCS filesSflag (1) a -t keyletter without a
			 filename causes removal of descriptive text (if any)
			 currently in the SCCS file, and (2) a -t keyletter
			 with a filename causes text (if any) in the named
			 file to replace the descriptive text (if any)
			 currently in the SCCS file.

	  -fflag	 This keyletter specifies a flag and, possibly, a
			 value for the flag to be placed in the SCCS file.
			 Several f keyletters may be supplied on a single
			 admin command line.  The allowable flags and their
			 values are

	       b	 Allows use of the -b keyletter on a get(1) command to
			 create branch deltas.

	       cceil	 The highest release (i.e., ``ceiling''), a number
			 greater than 0 but less than or equal to 9999, that
			 can be retrieved by a get(1) command for editing.
			 The default value for an unspecified c flag is 9999.

	       ffloor	 The lowest release (i.e., ``floor''), a number
			 greater than 0 but less than 9999, that can be
			 retrieved by a get(1) command for editing.  The
			 default value for an unspecified f flag is 1.

	       dSID	 The default delta number (SIDs+1) used by a get(1)
			 command.

	       i[str]	 Causes the "No id keywords (ge6)" message issued by
			 get(1) or delta(1) to be treated as a fatal error.
			 In the absence of this flag, the message is only a
			 warning.  The message is issued if no SCCS
			 identification keywords (see get(1)) are found in the
			 text retrieved or stored in the SCCS file.  If a
			 value is supplied, the keywords must match the given
			 string exactly; however, the string must contain a
			 keyword and no embedded newlines.

	       j	 Allows concurrent get(1) commands for editing on the
			 same SIDs+1 of an SCCS file.  This allows multiple
			 concurrent updates to the same version of the SCCS
			 file.

	       llist	 A list of releases to which deltas can no longer be
			 made (get -e against one of these ``locked'' releases
			 fails).  The list has the following syntax:

									Page 2

admin(1)							      admin(1)

	       <list>	 ::= <range> | <list> , <range>
			 <range>~::=	RELEASE NUMBER | a

			 The character a in the list is equivalent to
			 specifying all releases for the named SCCS file.

	       n	 Causes delta(1) to create a null delta in each of
			 those releases (if any) being skipped when a delta is
			 made in a new release (e.g., in making delta 5.1
			 after delta 2.7, releases 3 and 4 are skipped).
			 These null deltas serve as anchor points that branch
			 deltas may later be created from.  The absence of
			 this flag causes skipped releases to be nonexistent
			 in the SCCS file, preventing branch deltas from being
			 created from them in the future.

	       qtext	 User definable text substituted for all occurrences
			 of the %Q% keyword in the SCCS file text retrieved by
			 get(1).

	       mmod	 Module name of the SCCS file substituted for all
			 occurrences of the %M% keyword in the SCCS file text
			 retrieved by get(1).  If the m flag is not specified,
			 the value assigned is the name of the SCCS file with
			 the leading s. removed.

	       ttype	 Type of module in the SCCS file substituted for all
			 occurrences of %Y% keyword in the SCCS file text
			 retrieved by get(1).

	       vpgm	 Causes delta(1) to prompt for Modification Request
			 (MR) numbers as the reason for creating a delta.  The
			 optional value specifies the name of an MR number
			 validity checking program (see delta(1)).  (If this
			 flag is set when creating an SCCS file, the m
			 keyletter must also be used even if its value is
			 null.)

	  -dflag	 Causes removal (deletion) of the specified flag from
			 an SCCS file.	The -d keyletter may be specified only
			 when processing existing SCCS files.  Several -d
			 keyletters may be supplied on a single admin command.
			 See the -f keyletter for allowable flag names.

	       llist	 A list of releases to be ``unlocked.''	 See the -f
			 keyletter for a description of the l flag and the
			 syntax of a list.

	  -alogin	 A login name, or numeric UNIX system group ID, to be
			 added to the list of users that
			  make deltas (changes) to the SCCS file.  A group ID
			 is equivalent to specifying all login names common to

									Page 3

admin(1)							      admin(1)

			 that group ID.	 Several a keyletters may be used on a
			 single admin command line.  As many logins, or
			 numeric group ID's as desired may be on the list
			 simultaneously.  If the list of users is empty, then
			 anyone may add deltas.	 If a login or group ID is
			 preceded by a ! they are do not have permission to
			 make deltas.

	  -elogin	 A login name, or numeric group ID, to be erased from
			 the list of users allowed to make deltas (changes) to
			 the SCCS file.	 Specifying a group ID is equivalent
			 to specifying all login names common to that group
			 ID.  Several e keyletters may be used on a single
			 admin command line.

	  -m[mrlist]	 The list of Modification Requests (MR) numbers is
			 inserted into the SCCS file as the reason for
			 creating the initial delta in a manner identical to
			 delta(1).  The v flag must be set and the MR numbers
			 validated if the v flag has a value (the name of an
			 MR number validation program).	 Diagnostics will
			 occur if the v flag is not set or if MR validation
			 fails.

	  -y[comment]	 The comment text is inserted into the SCCS file as a
			 comment for the initial delta in a manner identical
			 to that of delta(1).  Omissing the -y keyletter
			 results in a default comment line being inserted in
			 the form

			 date and time created YY/MM/DD HH:MM:SS by login

			 The -y keyletter is valid only if the -i and/or -n
			 keyletters are specified (that is, a new SCCS file is
			 being created).

	  -h		 Causes admin to check the structure of the SCCS file
			 (see sccsfile(5)) and to compare a newly computed
			 check-sum (the sum of all the characters in the SCCS
			 file except those in the first line) with the check-
			 sum that is stored in the first line of the SCCS
			 file.	Appropriate error diagnostics are produced.

			 This keyletter inhibits writing on the file,
			 nullifying the effect of any other keyletters
			 supplied, and is, therefore, only meaningful when
			 processing existing files.

	  -z		 The SCCS file check-sum is recomputed and stored in
			 the first line of the SCCS file (see -h, above).

									Page 4

admin(1)							      admin(1)

			 Note that using this keyletter on a truly corrupted
			 file may prevent future detection of the corruption.

	  The last component of all SCCS filenames must be of the form
	  s.filename.  New SCCS files are given mode 444 (see chmod(1)).
	  Write permission in the pertinent directory is, of course, required
	  to create a file.  All writing done by admin is to a temporary x-
	  file, called x.filename (see get(1)), created with mode 444 if the
	  admin command is creating a new SCCS file or with the same mode as
	  the SCCS file if it exists.  After the successful execution of
	  admin, the SCCS file is removed (if it exists) and the x-file is
	  renamed with the name of the SCCS file.  This ensures that changes
	  are made to the SCCS file only if no errors occurred.

	  It is recommended that directories containing SCCS files be mode 755
	  and that SCCS files themselves be mode 444.  The mode of the
	  directories allows only the owner to modify SCCS files contained in
	  the directories.  The mode of the SCCS files prevents any
	  modification at all except by SCCS commands.

	  If it should be necessary to patch an SCCS file for any reason, the
	  mode may be changed to 644 by the owner allowing the use of ed(1).
	  Care must be taken! The edited file should always be processed by an
	  admin -h to check for corruption, followed by an admin -z to
	  generate a proper check-sum.	Another admin -h is recommended to
	  ensure the SCCS file is valid.

	  admin also makes use of a transient lock file (called z.filename),
	  to prevent simultaneous updates to the SCCS file by different users.
	  See get(1) for further information.

FILES
     g-file	      Existed before the execution of delta; removed after
		      completion of delta.
     p-file	      Existed before the execution of delta; may exist after
		      completion of delta.
     q-file	      Created during the execution of delta; removed after
		      completion of delta.
     x-file	      Created during the execution of delta; renamed to SCCS
		      file after completion of delta.
     z-file	      Created during the execution of delta; removed during
		      the execution of delta.
     d-file	      Created during the execution of delta; removed after
		      completion of delta.
     /usr/bin/bdiff   Program to compute differences between the ``gotten''
		      file and the g-file.

SEE ALSO
     delta(1), ed(1), get(1), help(1), prs(1), what(1), sccsfile(4).

									Page 5

admin(1)							      admin(1)

DIAGNOSTICS
     Use help(1) for explanations.

									Page 6

[top]

List of man pages available for IRIX

Copyright (c) for man pages and the logo by the respective OS vendor.

For those who want to learn more, the polarhome community provides shell access and support.

[legal] [privacy] [GNU] [policy] [cookies] [netiquette] [sponsors] [FAQ]
Tweet
Polarhome, production since 1999.
Member of Polarhome portal.
Based on Fawad Halim's script.
....................................................................
Vote for polarhome
Free Shell Accounts :: the biggest list on the net