---

3.1.2 admin options ¶

-axxx ¶

Add user or group xxx to the list of those authorised to check revisions in (that is, use get -e and delta). Users must be specified by name and groups by numeric ID.

This feature is often used in conjunction with a setuid installation of the sccs driver program (see sccs). This is not a good idea because the CSSC suite is not secure (see Known Problems).

-b ¶

Ensure that the file is encoded as a binary file. This option only works in conjunction with the -n or -i options.

This option is not available if binary file support is turned off (see Interoperability) though this can be re-enabled if necessary with an environment variable (see Environment Variables).

-dF

Delete flag F from the flags present in the file (see Flags). When using admin -dl to unlock a release, you need to specify which release should be unlocked. For example admin -dla unlocks all releases, while admin -dl2 unlocks only release 2. This means that admin -dl will do nothing, since no release was specified. If all releases are locked, attempting to unlock just one release will have no effect.

-exxx

Erase the specified user or group from the list of those authorised to check revisions in or out.

-fF[xxx]

Add the flag F (with optional value xxx) to the file’s flags (see Flags). For example, -fv/tmp/checkit sets the MR-validation flag to /tmp/checkit.

-h ¶

Check the SCCS file. The exit value will be 0 if the file is valid, and not 0 otherwise. The checks made are the same as those made for val. Some problems with the SCCS file may not be diagnosed.

Warning messages may be emitted, indicating things that may or may not be wrong (e.g. time apparently going backwards), but if no actual errors are encountered, the exit value will still be zero.

This option is silently incompatible with all the other options; the specified SCCS files will not be modified by admin if the -h flag is used.

-ifoo

Initialise the SCCS file with the contents of the file foo. If no argument is given, read from standard input. This implies the -n option.

-mMR-list

When initialising a file, add the specified list of MR numbers (see Modification Request Numbers) to the delta commentary for the initial version. The MR list is space-separated. It can also be empty (that is, just spaces). The specified MRs are validated according to the setting of the v flag, which should be set (see Flags). If the v flag is set but has no value (i.e. is set to the empty string), validation silently succeeds. If the v flag is not set, the -m option causes admin to fail. If you want to set the v flag when creating a history file but there are no appropriate MR numbers, you can specify an MR list containing just white space¹.

-n

Create a new SCCS file. Unless -i is also used, the new file will contain control information but the body will be initially empty. Some versions of SCCS require the -i option to be specified if ‘-n’ is used. Therefore for greatest portability, specify ‘-i/dev/null’ if you want an empty initial body. Interoperability.

-rN ¶

Set the initial release number to N. The initial level within that release is always 1. Some versions of SCCS allow you to specify actual an actual SID here (for example ‘1.2’ or ‘1.8.2.1’). CSSC also allows this, but emits a warning. If you use the -r option, you must also use the -i option (not just the -n option). If the initial SID you specify is not on the trunk, some tools will fail to work with the resulting file. See SCCS Version Differences.

-tdesc

Read in descriptive text for this file from desc. This replaces any existing description. If no argument, remove any existing description (this is illegal if -i or -n is used).

-V

Display version information.

-yadayada

When initialising a file, set the comment for that delta to adayada. If the option is given just as -y, the comment is recorded as empty. The following word in the argument list is not used as the comment. Note that this behaviour is different to most Unix programs, but is the same as the behaviour of traditional SCCS.

-z ¶

Fix the checksum information. The SCCS file is still validated by CSSC; apart from possibly having an incorrect checksum, the s-file must be valid. If you use this option on an SCCS file which really is invalid, then the attempt may fail or silently write out a valid but incorrect file. This option does not work on BitKeeper files. Use this option with extreme care.