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