Next: BitKeeper, Previous: Binary File Support, Up: Interoperability [Contents][Index]
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.
Next: BitKeeper, Previous: Binary File Support, Up: Interoperability [Contents][Index]