home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Frostbyte's 1980s DOS Shareware Collection
/
floppyshareware.zip
/
floppyshareware
/
USCX
/
FILEUT-2.ZIP
/
FCOMPARE.DOC
< prev
next >
Wrap
Text File
|
1985-05-02
|
2KB
|
45 lines
The FCOMPARE program implements Paul Heckel's algorithm from the
Communications of the ACM, April 1978, for detecting the differences
between two files. This algorithm has the advantage over more commonly
used compare algorithms that it is fast and can detect differences of an
arbitrary number of lines.
The command format is: FCOMPARE filespec1 filespec2 [options]
options:
Full - show full lines.
Brief - show first 34 characters of lines.
Tabs - expand tabs before comparing.
NOTabs - don't expand tabs.
TRim - ignore trailing blanks.
NOTRim - don't ignore trailing blanks.
(Only the capitalized part needs to be specified.)
Arbitrary path qualification is allowed in the filespecs. In addition,
the output can be redirected to the printer or a file with normal DOS
redirection conventions (e. g. >PRN).
By default (BRIEF), output is displayed with the two files side-by-side.
This is felt to make it easier to spot the location of differences, even
though only 34 characters of each record can be shown. The FULL option
causes the whole record to be shown. Along with each record displayed is
its line number in the file it came from.
If either file contains tabs, they will not be expanded before
comparison unless the TABS option is used. If TABS is not used, any tabs
in displayed records will probably make the output appear strange, since
they will be expanded by DOS.
The design limitations of the program are that only the first 256
characters of each record are compared, and only the first 5000 records
of a file. (Records are defined by the CRLF sequence.)
One possible but infrequent peculiarity of the algorithm is that records
that are not unique within a file and which are not adjacent to a record
which is unique and unchanged will be indicated as being different.
Since the program uses a hashing technique, it is possible, but very
unlikely, that different records could erroneously be considered equal.
It is even more unlikely that such an error would not be obvious in the
actual output, but you should be aware of the possibility if you use
this as the basis of a differential file maintenance technique.