home *** CD-ROM | disk | FTP | other *** search
/ Power Programming / powerprogramming1994.iso / progtool / filutl / brik2src.arc / BRIK.DOC < prev    next >
Text File  |  1989-08-04  |  29KB  |  705 lines

  1.  
  2.  
  3.      BRIK(1)                    USER MANUAL                    BRIK(1)
  4.  
  5.  
  6.      NAME
  7.           brik - calculate 32-bit CRC
  8.  
  9.      SYNOPSIS
  10.           brik -h
  11.           brik -gcGCbafvsqWHT file ...
  12.  
  13.      DESCRIPTION
  14.           Brik generates and verifies 32-bit CRC values (checksums).
  15.           It is designed to generate CRCs for text files that are the
  16.           same on all computer systems that use the ASCII character
  17.           set, provided each text file is in the usual text file
  18.           format for each system. Brik will also optionally use binary
  19.           CRCs calculated using every byte in a file.  Such binary
  20.           CRCs are portable across systems for binary files that are
  21.           moved from system to system without any newline conversion.
  22.           Brik can be asked to decide by examining each file whether
  23.           to calculate a text mode or binary mode CRC for it.
  24.  
  25.           Changes from version 1.0 are summarized at the end of this
  26.           document.
  27.  
  28.           The general usage format is:
  29.  
  30.                brik -gcGCbafvsqWHT [ file ] ...
  31.  
  32.           The brackets mean that file, which is the name of a file, is
  33.           optional.  The three dots indicate that more than one
  34.           filename may be typed (separated by blanks).  Exactly one of
  35.           the options -c, -C, -g, -G, or -h, is required.  The -h
  36.           option gives a help screen.
  37.  
  38.           In addition to -h, the Brik options available (as they
  39.           appear on the help screen) are:
  40.  
  41.           -g   look for Checksum: header, generate CRC for rest of
  42.                file
  43.  
  44.           -c   get CRC from header, verify CRC of rest of file
  45.  
  46.           -G   generate CRC for entire file (add -b for binary files)
  47.  
  48.           -C   verify all file CRCs from output of -G (-f is not
  49.                needed)
  50.  
  51.           -b   use binary mode -- read file byte by byte, not line by
  52.                line
  53.  
  54.           -a   automatically decide whether each file is text or
  55.                binary
  56.  
  57.           -f   read filenames (wildcards ok) from specified files
  58.  
  59.           -v   be verbose, report all results (else only errors are
  60.                reported)
  61.  
  62.           -s   be silent, say nothing, just return status code
  63.  
  64.           -q   be quiet, don't print header for -G
  65.  
  66.           -W   after generating CRC with -g, write it to original
  67.                header
  68.  
  69.           -H   after generating CRC with -g, print header to stdout
  70.  
  71.           -T   include trailing empty lines, normally ignored (text
  72.                mode only)
  73.  
  74.           VERIFYING CRC HEADERS
  75.  
  76.           The primary intended use of Brik is to verify Checksum:
  77.           headers in Usenet postings and in C and Pascal source files.
  78.           A Checksum: header looks like this:
  79.  
  80.                Checksum: 9485762645b   (verify with "brik")
  81.  
  82.           The word Checksum: must occur at the beginning of a line.
  83.           It is followed by a colon, an optional blank, a ten-digit
  84.           decimal 32-bit CRC, and any arbitrary optional string such
  85.           as the comment shown above.  The CRC value may be followed
  86.           by a one-character suffix identifying the type of the CRC.
  87.           These suffixes are described later.
  88.  
  89.           When Brik is invoked with the syntax
  90.  
  91.                brik -c file ...
  92.  
  93.           it will search for the Checksum: header in each specified
  94.           file, read the CRC value from that header, calculate the
  95.           CRC-32 for all lines in the file (except trailing empty
  96.           lines) that occur *after* the header line, and report an
  97.           error if the two values do not match.
  98.  
  99.           CALCULATING CRC HEADERS
  100.  
  101.           The command
  102.  
  103.                brik -g file ...
  104.  
  105.           tells Brik to look for the Checksum: header in each
  106.           specified file, calculate the CRC of the lines in the file
  107.           following the header, and print the CRC and filename without
  108.           changing the file in any way.  You can also ask Brik to
  109.           update the Checksum: header with the following command:
  110.  
  111.                brik -gW file ...
  112.  
  113.           This causes Brik to update the Checksum: header in the file
  114.           with the newly-calculated CRC.  If there is not enough space
  115.           for the CRC in the existing header, Brik reports an error
  116.           and does not change the existing header.  To initially add a
  117.           Checksum: header to a file, insert a line of the following
  118.           form into the file with a text editor:
  119.  
  120.                Checksum: XXXXXXXXXX  -- this is an optional comment
  121.  
  122.           The word Checksum must be at the beginning of a line.  The
  123.           ten `X' characters shown can be any ten characters.  They
  124.           will be later replaced by the calculated CRC value.  They do
  125.           not need to be `X'.  The comment following them is optional
  126.           and can be any arbitrary string of characters after the CRC
  127.           field, separated from it by blanks.  As an example, in a C
  128.           source file called main.c, you might have:
  129.  
  130.                /*
  131.                Checksum: XXXXXXXXXX  (verify or update with brik)
  132.                */
  133.  
  134.           Once a header like this exists in the file, invoke Brik as
  135.           follows:
  136.  
  137.                brik -gW main.c
  138.  
  139.           This will cause the ten `X' characters to be replaced with
  140.           the calculated checksum, giving something like this:
  141.  
  142.                /*
  143.                Checksum: 1922837484  (verify or update with brik)
  144.                */
  145.  
  146.           Later you can use the command
  147.  
  148.                brik -c main.c
  149.  
  150.           to verify that the contents of the file following the header
  151.           have the same CRC as the stored value.
  152.  
  153.           If Brik is invoked with the -c or -g options and it cannot
  154.           find a Checksum: header in a file, it prints a row of
  155.           question marks.  If it is invoked with the -gW option and it
  156.           does not find enough character positions after the Checksum:
  157.           string to hold the CRC, it does not fill in the CRC and
  158.           prints an error message.
  159.  
  160.           Brik can be asked to generate a complete Checksum: header
  161.           but print it to standard output instead of writing it to the
  162.           file.  Do this by adding the -H option.  If both -W and -H
  163.           are given, the Checksum: header will be written both to the
  164.           file and to standard output.
  165.  
  166.           WHOLE-FILE CRCS
  167.  
  168.           A "whole-file" CRC calculation is done for the entire
  169.           contents of a file, without looking for a Checksum: header.
  170.           The command
  171.  
  172.                brik -G file ...
  173.  
  174.           asks Brik to do this calculation for all specified files.
  175.           The output from this command is a list of files and their
  176.           whole-file CRCs.  It is sent to the standard output stream,
  177.           which in most cases is your screen.  The output should be
  178.           saved in a file by redirecting it.  For example, the command
  179.  
  180.                brik -G *.h *.c > crc.lst
  181.  
  182.           on an MS-DOS system might yield the following in the output
  183.           file crc.lst:
  184.  
  185.                # CRC-32        filename
  186.                # ------        --------
  187.  
  188.                2566277976      getopt.c
  189.                 100594287      brik.c
  190.                1151475469      vms.c
  191.                3929503738      turboc.c
  192.                2424271922      addbfcrc.c
  193.                1943472856      assert.h
  194.                2601923477      brik.h
  195.  
  196.           The output of the -G option is in free format.  The output
  197.           file may be edited by hand.  Empty lines and lines beginning
  198.           with '#' will be ignored by Brik when it is later asked to
  199.           read this file.
  200.  
  201.           This list of filenames and whole-file CRCs may be verified
  202.           by a command like this:
  203.  
  204.                brik -C crc.lst
  205.  
  206.           This makes Brik read the file crc.lst, get the CRCs and
  207.           filenames from it, do the CRC calculation again for each
  208.           file, and report an error if it does not match the CRC
  209.           recorded inside crc.lst.
  210.  
  211.           **IX and MS-DOS users (and others who can pipe the output of
  212.           one command into another) could use a command like the
  213.           following to see if Brik's -G and -C options are working:
  214.  
  215.                brik -G file ... | brik -C
  216.  
  217.           This invokes "brik -G" on some files, sending the output to
  218.           a pipe where it becomes the input of "brik -C".  If no
  219.           filename is specified, Brik reads from standard input, so
  220.           "brik -C" will read from the pipe and concurrently verify
  221.           all the CRCs that are being generated by "brik -G".
  222.  
  223.           Whole-file CRCs are normally generated in text mode, in
  224.           which a file is treated as lines of text.  You can also
  225.           generate whole-file CRCs in binary mode.  See below.
  226.  
  227.           BINARY VERSUS TEXT MODE
  228.  
  229.           Brik can work in two different modes.  The most common mode,
  230.           used unless you specify otherwise, is text mode.
  231.  
  232.           In this mode Brik reads all files line by line, and forces
  233.           each line of text to be terminated by a newline character of
  234.           constant value before doing a CRC calculation.  Thus, no
  235.           matter what newline character is used by your system, the
  236.           CRC calculation will be unaffected.  This means that whether
  237.           your operating system uses linefeeds to terminate lines
  238.           (e.g. **IX), or a carriage return and a linefeed (e.g. MS-
  239.           DOS) or a carriage return only (e.g. Macintosh) or nothing
  240.           but a record length field (e.g. VAX/VMS), the CRC
  241.           calculation in text mode gives the same results.
  242.  
  243.           If a file is not intended to be a text file, the text mode
  244.           CRC calculated by Brik may not be reliable and may be
  245.           different on different systems.  If Brik is calculating a
  246.           text mode CRC on a file that appears to contain binary data,
  247.           it still calculates the text-mode CRC but adds a "*"
  248.           character after the CRC to indicate to warn the user.
  249.  
  250.           Brik can be asked to operate in binary mode by adding a -b
  251.           option.  Binary mode is applicable only to the -G command,
  252.           which acts on whole files.  Thus
  253.  
  254.                brik -G file ...
  255.  
  256.           finds whole-file CRCs of all specified files in text mode,
  257.           while
  258.  
  259.                brik -Gb file ...
  260.  
  261.           does the same in binary mode.  In binary mode Brik simply
  262.           reads and calculates the CRC for all bytes in a file.  If a
  263.           file is moved from one system to another without any newline
  264.           conversion or any other changes, Brik should calculate the
  265.           same binary mode CRC for it on both systems.
  266.  
  267.           The output from "brik -Gb" includes a trailing b suffix in
  268.           each CRC, so "brik -C" will correctly use binary mode for
  269.           such CRCs and it is never necessary to type "brik -Cb"
  270.           instead.
  271.  
  272.           In its auto-check mode, Brik will itself examine each file
  273.           and determine whether it is a text or binary file and
  274.           calculate a CRC accordingly.  To do this, use the -a option.
  275.           Although Brik can determine the type of each file with a
  276.           high degree of reliability, it is still possible for it to
  277.           come to a wrong conclusion about some files.
  278.  
  279.           The output from "brik -Ga" will include a trailing b
  280.           character in the CRC for those files that appeared to be
  281.           binary to Brik.  You may find both text and binary CRCs in
  282.           the output.
  283.  
  284.           TRAILING EMPTY LINES
  285.  
  286.           The normal behavior of Brik in text mode is to ignore any
  287.           trailing empty lines in a file.  An empty line is a line
  288.           that contains nothing, not even blanks or tabs.  (Just
  289.           hitting a carriage return when you are editing a text file
  290.           usually produces an empty line.)  If manipulating a text
  291.           file causes trailing empty lines to be added or deleted, the
  292.           CRC calculated by Brik will be unaffected.  You can override
  293.           this if necessary with the -T option, which makes Brik
  294.           include trailing empty lines in the CRC calculation.  For
  295.           example,
  296.  
  297.                brik -gWT
  298.  
  299.           will update the Checksum: header with a CRC that includes
  300.           all lines in a text file.  Similarly
  301.  
  302.                brik -GT
  303.  
  304.           will find whole-file CRCs that include all lines in a text
  305.           file.
  306.  
  307.           When Brik is given the -T option, it adds a T suffix to each
  308.           generated CRC.  Then, when the CRC is verified with -c or
  309.           -C, Brik will correctly include trailing empty lines when
  310.           needed without having to be explicitly told to do so.
  311.  
  312.           In binary mode Brik always reads all bytes in a file, so it
  313.           does not ignore trailing empty lines, and the -T switch is
  314.           not needed.
  315.  
  316.           The effects of the -T and -b options are mutually exclusive.
  317.           If both are given, whichever is used later overrides the
  318.           first.  So -bT is equivalent to -T and -Tb is equivalent to
  319.           -T.
  320.  
  321.           FILENAME CONVENTIONS
  322.  
  323.           Under MS-DOS and VAX/VMS, wildcards are allowed on the
  324.           command line and will be expanded by Brik.  Under **IX,
  325.           wildcards are expected to be expanded by the shell and are
  326.           not expanded by Brik.  If no filename is given, Brik reads
  327.           its standard input.  By default this is keyboard input, but
  328.           it is expected that input will usually be redirected to come
  329.           from a file or a pipe.  Also, if a filename is explicitly
  330.           specified as a dash ("-"), it stands for standard input.
  331.  
  332.           The following five commands (valid under the **IX operating
  333.           system)
  334.  
  335.                brik -c myfile            # "myfile"
  336.                brik -c < myfile          # stdin = "myfile"
  337.                cat myfile | brik -c      # stdin = a pipe
  338.                brik -c - < myfile        # "-" = stdin = "myfile"
  339.                cat myfile | brik -c -    # "-" = stdin = a pipe
  340.  
  341.           all have the effect of verifying the Checksum: header in the
  342.           file myfile.
  343.  
  344.           Standard input can also be read when using the -C option.
  345.           For example, suppose we have already given the command
  346.  
  347.                brik -G *.c *.h > crc.lst
  348.  
  349.           to create a file called "crc.lst" that contains a list of
  350.           whole-file CRCs.  We can now verify the integrity of these
  351.           files with any of the following commands:
  352.  
  353.                brik -C crc.lst          # "crc.lst"
  354.                brik -C < crc.lst        # stdin = "crc.lst"
  355.                brik -C - < crc.lst      # "-" = stdin = "crc.lst"
  356.                cat crc.lst | brik -C    # stdin = a pipe
  357.                cat crc.lst | brik -C -  # "-" = stdin = a pipe
  358.  
  359.  
  360.           INDIRECT FILE NAMING
  361.  
  362.           The -f option allows you to have filenames in a list rather
  363.           than on the command line.  For example, suppose you want to
  364.           generate whole-file CRCs of files whose names are selected
  365.           by some other program.  You could use find (under **IX) or
  366.           Stuff (under MS-DOS) to generate a list of filenames.  When
  367.           the -f option is given, Brik reads filenames, one per line,
  368.           from the file(s) specified.  Thus you could do the
  369.           following:
  370.  
  371.                find . -mtime +3 -print > flist
  372.                brik -Gf flist > crc.lst
  373.  
  374.           The first command asks find to generate a list of names of
  375.           all files that were modified more than 3 days ago, and sends
  376.           the output to the file flist.  The contents of flist might
  377.           now look like this, as an example:
  378.  
  379.                ./sez.doc
  380.                ./brik.doc
  381.                ./stuff.doc
  382.                ./looz.doc
  383.  
  384.           The second command above asks Brik to read the file called
  385.           flist, get a list of filenames from it, one per line, and
  386.           generate the whole-file CRC of each of these files.  We
  387.           additionally redirect the output of "brik -Gf" to the file
  388.           called crc.lst.  Given the above contents of flist, the
  389.           following two commands are exactly equivalent:
  390.  
  391.                brik -Gf flist >crc.lst
  392.                brik -G ./sez.doc ./brik.doc ./stuff.doc ./looz.doc >crc.lst
  393.  
  394.           The advantage of the -f option is that once you have
  395.           filenames in a file, you need not type them again at the
  396.           command line.  The -f option also allows you to feed Brik
  397.           through a pipe filenames generated by another program.
  398.           Consider this command:
  399.  
  400.                find . -mtime +3 -print | brik -Gf - > crc.lst
  401.  
  402.           Under **IX this concurrently invokes both find and Brik.  As
  403.           find generates a filename and sends it to its standard
  404.           output (a pipe), Brik reads the filename from its standard
  405.           input and generates its whole-file CRC.  The following
  406.           pipeline
  407.  
  408.                find . -mtime +3 -print | brik -Gf - | brik -C -
  409.  
  410.           invokes find to generate filenames, Brik to print the
  411.           whole-file CRCs of those files, and Brik again to
  412.           immediately verify them.
  413.  
  414.           Under MS-DOS and VAX/VMS (and any other operating system
  415.           under which Brik has been installed to expand wildcards
  416.           itself), a file specified by the -f option can itself
  417.           contain wildcards in the filenames.  For example, suppose
  418.           the file "wildfile" contains the following lines:
  419.  
  420.                /bin/*.exe
  421.                /bin/*.com
  422.                /doc/*.doc
  423.  
  424.           Now if we invoke Brik with the command
  425.  
  426.                brik -Gf wildfile
  427.  
  428.           it will read filespecs from "wildfile," expand wildcards in
  429.           each filespec, and generate whole-file CRCs for all matching
  430.           files.
  431.  
  432.           If you are checking whole-file CRCs with the -C option, you
  433.           do not normally need to use the -f option.  When used with
  434.           -C, the -f option introduces an additional level of file
  435.           naming indirection. For example, the command
  436.  
  437.                brik -C crc.lst
  438.  
  439.           takes a list of CRCs and filenames from "crc.lst" and
  440.           verifies them.  However, the command
  441.  
  442.                brik -Cf master.lst
  443.  
  444.           does not do the same thing.  Instead, it takes a list of
  445.           files from "master.lst," looks inside each of those files
  446.           for a list of CRCs and filenames, and verifies them.
  447.  
  448.           As an example of the use of -Cf, consider this sequence:
  449.  
  450.                brik -Gb /bin/*.exe > exelist
  451.                brik -Gb /bin/*.com > comlist
  452.                brik -GT /doc/*.doc > doclist
  453.                brik -G  /doc/*.man > manlist
  454.  
  455.           Now we have four files called "exelist," "comlist,"
  456.           "doclist," and "manlist" containing whole-file CRCs of
  457.           various types.  We can test the integrity of files listed in
  458.           these in four separate commands like this:
  459.  
  460.                brik -C exelist
  461.                brik -C comlist
  462.                brik -C doclist
  463.                brik -C manlist
  464.  
  465.           But we could also do this in a single step by first creating
  466.           a file called "biglist" that contains the names of these
  467.           four files:
  468.  
  469.                exelist
  470.                comlist
  471.                doclist
  472.                manlist
  473.  
  474.           and then use -Cf thus:
  475.  
  476.                brik -Cf biglist
  477.  
  478.           This causes Brik to read filenames from "biglist," look
  479.           inside each of those files ("exelist," "comlist," "doclist,"
  480.           and "manlist") and check the CRCs found there.  A **IX
  481.           example to do the same thing in a more compact way might be:
  482.  
  483.                cat exelist comlist doclist manlist | brik -Cf -
  484.  
  485.           The above examples are somewhat contrived, however.  We
  486.           could also use the following command:
  487.  
  488.                brik -C exelist comlist doclist manlist
  489.  
  490.  
  491.           SILENT VERSUS VERBOSE VERSUS QUIET
  492.  
  493.           Brik accepts options -s, -q, and -v that control the degree
  494.           of verbosity.
  495.  
  496.           Normally Brik prints a message only if it detects an error.
  497.           For example, if you give the command
  498.  
  499.                brik -c *.c *.h
  500.  
  501.           and Brik finds that all Checksum: headers contain CRCs that
  502.           match the calculated value, it prints nothing.
  503.  
  504.           The -v switch makes Brik print a message for each file
  505.           tested that contains the word "ok" if stored and calculated
  506.           CRCs matched and "BAD" if they did not.
  507.  
  508.           In all messages reporting file CRCs, Brik prints the actual
  509.           CRC it calculated, or a row of question marks if it could
  510.           not calculate one.  Brik fails to calculate a CRC if it is
  511.           trying to calculate a header-based CRC (commands -c and -g)
  512.           but does not find a Checksum: header in a file.
  513.  
  514.           The -s switch tells Brik to be silent.  This will cause
  515.           nothing to be printed if Brik does not find a Checksum
  516.           header or if CRCs don't match.  However, the status code on
  517.           exit is still set.  The -s option is useful for invoking
  518.           Brik from within a shell script (**IX) or a batch file (MS-
  519.           DOS) and later testing the error code it returned when it
  520.           exited.
  521.  
  522.           The -s switch does not suppress the error message printed if
  523.           Brik is given a filename and the file cannot be found.  For
  524.           example, if the command
  525.  
  526.                brik -cs myfile
  527.  
  528.           is given but "myfile" does not exist, Brik will print an
  529.           error message even though the -s option was given.
  530.  
  531.           The -q switch makes Brik slightly quieter.  Its only effect
  532.           is to suppress the introductory comments that are otherwise
  533.           generated by the -C option.
  534.  
  535.           VAX/VMS BUGS
  536.  
  537.           o    Under VAX/VMS, file manipulation is unpredictable and
  538.                the VAX/VMS C runtime library in particular is very
  539.                unreliable.  One result is that under VAX/VMS, the -gW
  540.                option will work only for stream-LF files, which are
  541.                the only type of file that VAX/VMS seems to handle
  542.                correctly.  Fortunately, the -c option will correctly
  543.                work for VAX/VMS standard text files.
  544.  
  545.           o    The VAX/VMS implementation of Brik simply ignores
  546.                filenames that correspond to nonexistent files instead
  547.                of giving an error message.  VMS users are invited to
  548.                fix this bug (probably somewhere in the nextfile()
  549.                function in the file vms.c) and send me the fix.
  550.  
  551.           o    To avoid annoying error messages, Brik under VAX/VMS
  552.                always exits with a status code of 1.
  553.  
  554.           o    Due to a problem in the VAX/VMS command interpreter, if
  555.                any uppercase option characters are typed (e.g. -C, -G,
  556.                -T), Brik will not recognize them as uppercase unless
  557.                they are enclosed in double quotes.  An example of a
  558.                correct command under VAX/VMS:
  559.  
  560.                  brik "-GT" *.*
  561.  
  562.                An example of a command that won't work:
  563.  
  564.                  brik -GT *.*
  565.  
  566.           USAGE HINTS
  567.  
  568.           This section discusses some ways of using Brik.
  569.  
  570.           -    Brik is currently used to create and verify checksums
  571.                of articles posted on the Usenet newsgroup
  572.                comp.binaries.ibm.pc.  While reading Usenet news with
  573.                rn, for example, you can verify the Checksum: header of
  574.                such an article with the command:
  575.  
  576.                  | brik -cv
  577.  
  578.                This feeds the current article to Brik as standard
  579.                input and asks it to verbosely verify the checksum.
  580.  
  581.           -    C and Pascal source files that are being distributed
  582.                can be given their own Checksum: headers.  The
  583.                advantage of this over listing CRCs separately is that
  584.                each file contains its checksum no matter where it
  585.                goes.  The recipient can easily verify that each source
  586.                file was received intact.  This is especially valuable
  587.                when source files are being sent by electronic mail
  588.                through an IBM mainframe-based network, such as BITNET,
  589.                that can cause corruption of text files.
  590.  
  591.                Create the Checksum header with a text editor and
  592.                initialize its value with the command:
  593.  
  594.                  brik -gW file ...
  595.  
  596.                The recipient can verify the checksum with the command:
  597.  
  598.                  brik -cv file ...
  599.  
  600.           -    To keep track of any unexpected filesystem corruption
  601.                or unauthorized changes to system files, Brik can be
  602.                used to create a list of checksums.  This should be
  603.                done using the -b option (all binary checksums) or the
  604.                -a option (use text or binary as appropriate).  Under
  605.                **IX this can be done with a command like this one:
  606.  
  607.                  find /bin /usr/bin /lib /usr/lib /usr/new \
  608.                   -type f -print | \
  609.                  grep -v '^/usr/bin/beta' | \
  610.                  grep -v '^/usr/new/lib/news' | \
  611.                  brik -Gbf - > crc.list
  612.  
  613.                This example uses find to print the pathnames of
  614.                certain files, grep to filter out certain directory
  615.                subtrees, and then Brik to print checksums of all
  616.                selected files.  Periodically a background job can be
  617.                run to compare the file list against current files and
  618.                report any discrepancies:
  619.  
  620.                  brik -C crc.lst | mail -s 'brik output' postmaster
  621.  
  622.                Under MS-DOS, create a list of checksums with the help
  623.                of Stuff, a find-like file finder program that is
  624.                distributed with zoo 2.01:
  625.  
  626.                  stuff /bin /msdos /turboc | brik -Gaf - > crc.list
  627.  
  628.                This is a simple mechanism that can be used to detect
  629.                unexpected file changes caused by hardware problems or
  630.                malicious programs such as viruses and worms.  Be
  631.                warned, however, that since Brik uses a published CRC
  632.                algorithm, very clever deviant programs are possible
  633.                that could change a file without affecting its CRC.
  634.  
  635.                To avoid too many false alarms, only files that do not
  636.                change much (such as system binaries) should be
  637.                selected.
  638.  
  639.      CHANGES
  640.           Changes from version 1.0 are as follows.
  641.  
  642.           -    The CRC calculation has been recoded in 8086 assembly
  643.                code suitable for Turbo C/MS-DOS.  As a result Brik 2.0
  644.                under MS-DOS is much faster than version 1.0.
  645.  
  646.           -    The new -a flag makes Brik automatically determine for
  647.                each file whether it is text or binary and calculate
  648.                the CRC accordingly
  649.  
  650.           -    When Brik is asked to calculate a text mode CRC but the
  651.                file appears to be binary, it now does not print a
  652.                warning message but instead adds a "*" suffix to the
  653.                calculated CRC to indicate that the CRC may not be
  654.                reliable.
  655.  
  656.           -    The new -H flag makes Brik print the formatted
  657.                Checksum: header to standard output.
  658.  
  659.           -    Detection of binary files is now more reliable under
  660.                MS-DOS.  If a control Z character occurs near the
  661.                beginning of a binary file, Brik will not be fooled by
  662.                the apparent end-of-file but will in most cases
  663.                reliably detect that the file is binary.
  664.  
  665.           -    The new -q flag suppresses the introductory comments
  666.                from the output of the -G command.
  667.  
  668.      BUGS
  669.           Brik is designed to work with computer systems that use the
  670.           7-bit ASCII character set and 8-bit bytes with the eighth
  671.           (parity) bit set to zero.
  672.  
  673.           Brik has not been tested with computer systems that use
  674.           ASCII characters with the eighth bit set or those that use
  675.           EBCDIC characters.  Although it will calculate a CRC on such
  676.           machines, the probability of this CRC being the same as the
  677.           one calculated on machines that use 7-bit ASCII is
  678.           approximately 0.00000000023.
  679.  
  680.      DIAGNOSTICS
  681.           Error messages are intended to be self-explanatory.
  682.  
  683.           The exit status returned is 1 if Brik was invoked with
  684.           incorrect arguments, else it is the number of files found
  685.           with missing or invalid CRCs, but not greater than an
  686.           operating-system-dependent maximum value.
  687.  
  688.      COPYRIGHT
  689.           Both this documentation and Brik are Copyright 1989 Rahul
  690.           Dhesi, all rights reserved.  Permission is granted to copy,
  691.           use, and distribute for any commercial or noncommercial
  692.           purpose in accordance with the requirements of version 1.0
  693.           of the GNU General Public license.
  694.  
  695.           Note:  This software has not been endorsed by the Free
  696.           Software Foundation, the creator of the GNU license, and I
  697.           am not affiliated with that organization.
  698.  
  699.      AUTHOR
  700.           Rahul Dhesi
  701.           UUCP: {iuvax,pur-ee}!bsu-cs!dhesi
  702.           Internet: dhesi@bsu-cs.bsu.edu
  703.  
  704.      BRIK(1)                    USER MANUAL                (1989/07/11)
  705.