### 6.2 Executable File Support

The support that CSSC provides for binary files allows the controlled file to contain any sequence of bytes. That doesn’t imply that the controlled file is used for any particular purpose. For example, JPEG files can contain non-ASCII acharacters.

This should be contrasted with support for executable files, which have a specific Unix file mode bit set (see the manual page for `chmod` for more details). Unix executable files may or may not be binary files. It’s common to control shell scripts with CSSC, for example. Shell scripts are normaly executable but not binary.

If the `x` flag is set, CSSC will generate a g-file whose execute bits are set. This feature exists for compatibility with SCO OpenServer’s SCCS. Do not use this feature if you wish to interoperate with other implementations of SCCS. Setting this flag with `admin -fx` generates a warning about this.

A more portable alternative is for the history file itself to be executable. When this is the case, the mode of the gotten file is also executable (subject to the current umask value). When a history file is created with `admin -i`, the history file is created with execute bits set (subject to the current umask value) if the input file is executable. This usage of `admin -i` does not set the `x` flag in the history file.

When no argument is specified to the ‘`-i`’ option of `admin`, the initial file body is taken from stdin. If stdin is redirected from an file with an execute permission bit set in its mode, the history file will also be executable (subject to the umask setting).

This behaviour (of setting and using the execute permissions on the history file) follows that of Solaris; other SCCS implementations may not do this.