8.3 Unemulated Features
There are some features of (some implementations of) the traditional
sccs suite which it may not be desirable to copy.
- If an sccs file is created with the -i option, and it turns
out to need encoding, then genuine sccs seeks back to the start of
the file and encodes it. However, if the input file is not seekable,
for example if it is a pipe, then this doesn't always work. The
sccs file is then sometimes created containing only the initial
part of the body, before the offending segment of the file. The exit
value of the
admin
program is nevertheless still zero. Tests for
this situation are in tests/binary/seeking.sh but these tests are
only carried out if the program under test seems to be cssc rather
than the genuine sccs suite. The cssc suite does not have
this problem, and will always detect the need to encode the file, and
will successfully complete the process (it does not try to seek on the
input pipe).
- The normal configuration for cssc is that it supports binary files
and has no limit on line length in file with which it deals. Both of
these features may be different to the features of some version of
sccs with which you want to interoperate. See
Interoperability for more information on how to achieve better
interoperability with other implementations of sccs.
- If you have a hard link to an sccs file, then sccs programs
would “break” the hard link because the sccs file is
rewritten. For this reason, sccs checks the link count on the
file before using it. The sccs suite also does this. While
cssc does this consistently, sccs does not - for example the
val program does not do this check.
There are also a small number of respects in which various
implementations differ from each other; in such cases cssc picks
a suitable alternative; SCCS Version Differences.