


BRIK(1)             RISC/os Reference Manual              BRIK(1)



NAME
     brik - calculate 32-bit CRC

SYNOPSIS
     brik -h
     brik -gcGCbafvsqWHT _f_i_l_e ...

DESCRIPTION
     _B_r_i_k generates and verifies 32-bit CRC values (checksums).
     It is designed to generate CRCs for text files that are the
     same on all computer systems that use the ASCII character
     set, provided each text file is in the usual text file for-
     mat for each system. _B_r_i_k will also optionally use binary
     CRCs calculated using every byte in a file.  Such binary
     CRCs are portable across systems for binary files that are
     moved from system to system without any newline conversion.
     _B_r_i_k can be asked to decide by examining each file whether
     to calculate a text mode or binary mode CRC for it.

     Changes from version 1.0 are summarized at the end of this
     document.

     The general usage format is:

          brik -gcGCbafvsqWHT [ _f_i_l_e ] ...

     The brackets mean that _f_i_l_e, which is the name of a file, is
     optional.  The three dots indicate that more than one
     filename may be typed (separated by blanks).  Exactly one of
     the options -c, -C, -g, -G, or -h, is required.  The -h
     option gives a help screen.

     In addition to -h, the _B_r_i_k options available (as they
     appear on the help screen) are:

     -g   look for _C_h_e_c_k_s_u_m: header, generate CRC for rest of
          file

     -c   get CRC from header, verify CRC of rest of file

     -G   generate CRC for entire file (add -b for binary files)

     -C   verify all file CRCs from output of -G (-f is not
          needed)

     -b   use binary mode -- read file byte by byte, not line by
          line

     -a   automatically decide whether each file is text or
          binary

     -f   read filenames (wildcards ok) from specified files



Printed 0/0/0              Jul 8, 1989                          1






BRIK(1)             RISC/os Reference Manual              BRIK(1)



     -v   be verbose, report all results (else only errors are
          reported)

     -s   be silent, say nothing, just return status code

     -q   be quiet, don't print header for -G

     -W   after generating CRC with -g, write it to original
          header

     -H   after generating CRC with -g, print header to stdout

     -T   include trailing empty lines, normally ignored (text
          mode only)

     VERIFYING CRC HEADERS

     The primary intended use of _B_r_i_k is to verify _C_h_e_c_k_s_u_m:
     headers in Usenet postings and in C and Pascal source files.
     A _C_h_e_c_k_s_u_m: header looks like this:

          Checksum: 9485762645b   (verify with "brik")

     The word _C_h_e_c_k_s_u_m: must occur at the beginning of a line.
     It is followed by a colon, an optional blank, a ten-digit
     decimal 32-bit CRC, and any arbitrary optional string such
     as the comment shown above.  The CRC value may be followed
     by a one-character suffix identifying the type of the CRC.
     These suffixes are described later.

     When _B_r_i_k is invoked with the syntax

          brik -c _f_i_l_e ...

     it will search for the _C_h_e_c_k_s_u_m: header in each specified
     _f_i_l_e, read the CRC value from that header, calculate the
     CRC-32 for all lines in the file (except trailing empty
     lines) that occur *after* the header line, and report an
     error if the two values do not match.

     CALCULATING CRC HEADERS

     The command

          brik -g _f_i_l_e ...

     tells _B_r_i_k to look for the _C_h_e_c_k_s_u_m: header in each speci-
     fied _f_i_l_e, calculate the CRC of the lines in the file fol-
     lowing the header, and print the CRC and filename without
     changing the file in any way.  You can also ask _B_r_i_k to
     update the _C_h_e_c_k_s_u_m: header with the following command:




Printed 0/0/0              Jul 8, 1989                          2






BRIK(1)             RISC/os Reference Manual              BRIK(1)



          brik -gW _f_i_l_e ...

     This causes _B_r_i_k to update the _C_h_e_c_k_s_u_m: header in the file
     with the newly-calculated CRC.  If there is not enough space
     for the CRC in the existing header, _B_r_i_k reports an error
     and does not change the existing header.  To initially add a
     _C_h_e_c_k_s_u_m: header to a file, insert a line of the following
     form into the file with a text editor:

          Checksum: XXXXXXXXXX  -- this is an optional comment

     The word _C_h_e_c_k_s_u_m must be at the beginning of a line.  The
     ten `X' characters shown can be any ten characters.  They
     will be later replaced by the calculated CRC value.  They do
     not need to be `X'.  The comment following them is optional
     and can be any arbitrary string of characters after the CRC
     field, separated from it by blanks.  As an example, in a C
     source file called _m_a_i_n._c, you might have:

          /*
          Checksum: XXXXXXXXXX  (verify or update with brik)
          */

     Once a header like this exists in the file, invoke _B_r_i_k as
     follows:

          brik -gW main.c

     This will cause the ten `X' characters to be replaced with
     the calculated checksum, giving something like this:

          /*
          Checksum: 1922837484  (verify or update with brik)
          */

     Later you can use the command

          brik -c main.c

     to verify that the contents of the file following the header
     have the same CRC as the stored value.

     If _B_r_i_k is invoked with the -c or -g options and it cannot
     find a _C_h_e_c_k_s_u_m: header in a file, it prints a row of ques-
     tion marks.  If it is invoked with the -gW option and it
     does not find enough character positions after the _C_h_e_c_k_s_u_m:
     string to hold the CRC, it does not fill in the CRC and
     prints an error message.

     _B_r_i_k can be asked to generate a complete _C_h_e_c_k_s_u_m: header
     but print it to standard output instead of writing it to the
     file.  Do this by adding the -H option.  If both -W and -H



Printed 0/0/0              Jul 8, 1989                          3






BRIK(1)             RISC/os Reference Manual              BRIK(1)



     are given, the _C_h_e_c_k_s_u_m: header will be written both to the
     file and to standard output.

     WHOLE-FILE CRCS

     A "whole-file" CRC calculation is done for the entire con-
     tents of a file, without looking for a _C_h_e_c_k_s_u_m: header.
     The command

          brik -G _f_i_l_e ...

     asks _B_r_i_k to do this calculation for all specified files.
     The output from this command is a list of files and their
     whole-file CRCs.  It is sent to the standard output stream,
     which in most cases is your screen.  The output should be
     saved in a file by redirecting it.  For example, the command

          brik -G *.h *.c > crc.lst

     on an MS-DOS system might yield the following in the output
     file _c_r_c._l_s_t:

          # CRC-32        filename
          # ------        --------

          2566277976      getopt.c
           100594287      brik.c
          1151475469      vms.c
          3929503738      turboc.c
          2424271922      addbfcrc.c
          1943472856      assert.h
          2601923477      brik.h

     The output of the -G option is in free format.  The output
     file may be edited by hand.  Empty lines and lines beginning
     with '#' will be ignored by _B_r_i_k when it is later asked to
     read this file.

     This list of filenames and whole-file CRCs may be verified
     by a command like this:

          brik -C crc.lst

     This makes _B_r_i_k read the file _c_r_c._l_s_t, get the CRCs and
     filenames from it, do the CRC calculation again for each
     file, and report an error if it does not match the CRC
     recorded inside _c_r_c._l_s_t.

     **IX and MS-DOS users (and others who can pipe the output of
     one command into another) could use a command like the fol-
     lowing to see if _B_r_i_k'_s -G and -C options are working:




Printed 0/0/0              Jul 8, 1989                          4






BRIK(1)             RISC/os Reference Manual              BRIK(1)



          brik -G file ... | brik -C

     This invokes "brik -G" on some files, sending the output to
     a pipe where it becomes the input of "brik -C".  If no
     filename is specified, _B_r_i_k reads from standard input, so
     "brik -C" will read from the pipe and concurrently verify
     all the CRCs that are being generated by "brik -G".

     Whole-file CRCs are normally generated in text mode, in
     which a file is treated as lines of text.  You can also gen-
     erate whole-file CRCs in binary mode.  See below.

     BINARY VERSUS TEXT MODE

     _B_r_i_k can work in two different modes.  The most common mode,
     used unless you specify otherwise, is text mode.

     In this mode _B_r_i_k reads all files line by line, and forces
     each line of text to be terminated by a newline character of
     constant value before doing a CRC calculation.  Thus, no
     matter what newline character is used by your system, the
     CRC calculation will be unaffected.  This means that whether
     your operating system uses linefeeds to terminate lines
     (e.g. **IX), or a carriage return and a linefeed (e.g. MS-
     DOS) or a carriage return only (e.g. Macintosh) or nothing
     but a record length field (e.g. VAX/VMS), the CRC calcula-
     tion in text mode gives the same results.

     If a file is not intended to be a text file, the text mode
     CRC calculated by _B_r_i_k may not be reliable and may be dif-
     ferent on different systems.  If _B_r_i_k is calculating a text
     mode CRC on a file that appears to contain binary data, it
     still calculates the text-mode CRC but adds a "*" character
     after the CRC to indicate to warn the user.

     _B_r_i_k can be asked to operate in binary mode by adding a -b
     option.  Binary mode is applicable only to the -G command,
     which acts on whole files.  Thus

          brik -G _f_i_l_e ...

     finds whole-file CRCs of all specified files in text mode,
     while

          brik -Gb _f_i_l_e ...

     does the same in binary mode.  In binary mode _B_r_i_k simply
     reads and calculates the CRC for all bytes in a file.  If a
     file is moved from one system to another without any newline
     conversion or any other changes, _B_r_i_k should calculate the
     same binary mode CRC for it on both systems.




Printed 0/0/0              Jul 8, 1989                          5






BRIK(1)             RISC/os Reference Manual              BRIK(1)



     The output from "brik -Gb" includes a trailing b suffix in
     each CRC, so "brik -C" will correctly use binary mode for
     such CRCs and it is never necessary to type "brik -Cb"
     instead.

     In its auto-check mode, _B_r_i_k will itself examine each file
     and determine whether it is a text or binary file and calcu-
     late a CRC accordingly.  To do this, use the -a option.
     Although _B_r_i_k can determine the type of each file with a
     high degree of reliability, it is still possible for it to
     come to a wrong conclusion about some files.

     The output from "brik -Ga" will include a trailing b charac-
     ter in the CRC for those files that appeared to be binary to
     _B_r_i_k.  You may find both text and binary CRCs in the output.

     TRAILING EMPTY LINES

     The normal behavior of _B_r_i_k in text mode is to ignore any
     trailing empty lines in a file.  An empty line is a line
     that contains nothing, not even blanks or tabs.  (Just hit-
     ting a carriage return when you are editing a text file usu-
     ally produces an empty line.)  If manipulating a text file
     causes trailing empty lines to be added or deleted, the CRC
     calculated by _B_r_i_k will be unaffected.  You can override
     this if necessary with the -T option, which makes _B_r_i_k
     include trailing empty lines in the CRC calculation.  For
     example,

          brik -gWT

     will update the _C_h_e_c_k_s_u_m: header with a CRC that includes
     all lines in a text file.  Similarly

          brik -GT

     will find whole-file CRCs that include all lines in a text
     file.

     When _B_r_i_k is given the -T option, it adds a T suffix to each
     generated CRC.  Then, when the CRC is verified with -c or
     -C, _B_r_i_k will correctly include trailing empty lines when
     needed without having to be explicitly told to do so.

     In binary mode _B_r_i_k always reads all bytes in a file, so it
     does not ignore trailing empty lines, and the -T switch is
     not needed.

     The effects of the -T and -b options are mutually exclusive.
     If both are given, whichever is used later overrides the
     first.  So -bT is equivalent to -T and -Tb is equivalent to
     -T.



Printed 0/0/0              Jul 8, 1989                          6






BRIK(1)             RISC/os Reference Manual              BRIK(1)



     FILENAME CONVENTIONS

     Under MS-DOS and VAX/VMS, wildcards are allowed on the com-
     mand line and will be expanded by _B_r_i_k.  Under **IX, wild-
     cards are expected to be expanded by the shell and are not
     expanded by _B_r_i_k.  If no filename is given, _B_r_i_k reads its
     standard input.  By default this is keyboard input, but it
     is expected that input will usually be redirected to come
     from a file or a pipe.  Also, if a filename is explicitly
     specified as a dash ("-"), it stands for standard input.

     The following five commands (valid under the **IX operating
     system)

          brik -c myfile            # "myfile"
          brik -c < myfile          # stdin = "myfile"
          cat myfile | brik -c      # stdin = a pipe
          brik -c - < myfile        # "-" = stdin = "myfile"
          cat myfile | brik -c -    # "-" = stdin = a pipe

     all have the effect of verifying the _C_h_e_c_k_s_u_m: header in the
     file _m_y_f_i_l_e.

     Standard input can also be read when using the -C option.
     For example, suppose we have already given the command

          brik -G *.c *.h > crc.lst

     to create a file called "crc.lst" that contains a list of
     whole-file CRCs.  We can now verify the integrity of these
     files with any of the following commands:

          brik -C crc.lst          # "crc.lst"
          brik -C < crc.lst        # stdin = "crc.lst"
          brik -C - < crc.lst      # "-" = stdin = "crc.lst"
          cat crc.lst | brik -C    # stdin = a pipe
          cat crc.lst | brik -C -  # "-" = stdin = a pipe


     INDIRECT FILE NAMING

     The -f option allows you to have filenames in a list rather
     than on the command line.  For example, suppose you want to
     generate whole-file CRCs of files whose names are selected
     by some other program.  You could use _f_i_n_d (under **IX) or
     _S_t_u_f_f (under MS-DOS) to generate a list of filenames.  When
     the -f option is given, _B_r_i_k reads filenames, one per line,
     from the file(s) specified.  Thus you could do the follow-
     ing:

          find . -mtime +3 -print > flist
          brik -Gf flist > crc.lst



Printed 0/0/0              Jul 8, 1989                          7






BRIK(1)             RISC/os Reference Manual              BRIK(1)



     The first command asks _f_i_n_d to generate a list of names of
     all files that were modified more than 3 days ago, and sends
     the output to the file _f_l_i_s_t.  The contents of _f_l_i_s_t might
     now look like this, as an example:

          ./sez.doc
          ./brik.doc
          ./stuff.doc
          ./looz.doc

     The second command above asks _B_r_i_k to read the file called
     _f_l_i_s_t, get a list of filenames from it, one per line, and
     generate the whole-file CRC of each of these files.  We
     additionally redirect the output of "brik -Gf" to the file
     called _c_r_c._l_s_t.  Given the above contents of _f_l_i_s_t, the fol-
     lowing two commands are exactly equivalent:

          brik -Gf flist >crc.lst
          brik -G ./sez.doc ./brik.doc ./stuff.doc ./looz.doc >crc.lst

     The advantage of the -f option is that once you have
     filenames in a file, you need not type them again at the
     command line.  The -f option also allows you to feed _B_r_i_k
     through a pipe filenames generated by another program.  Con-
     sider this command:

          find . -mtime +3 -print | brik -Gf - > crc.lst

     Under **IX this concurrently invokes both _f_i_n_d and _B_r_i_k.  As
     _f_i_n_d generates a filename and sends it to its standard out-
     put (a pipe), _B_r_i_k reads the filename from its standard
     input and generates its whole-file CRC.  The following pipe-
     line

          find . -mtime +3 -print | brik -Gf - | brik -C -

     invokes _f_i_n_d to generate filenames, _B_r_i_k to print the
     whole-file CRCs of those files, and _B_r_i_k again to immedi-
     ately verify them.

     Under MS-DOS and VAX/VMS (and any other operating system
     under which _B_r_i_k has been installed to expand wildcards
     itself), a file specified by the -f option can itself con-
     tain wildcards in the filenames.  For example, suppose the
     file "wildfile" contains the following lines:

          /bin/*.exe
          /bin/*.com
          /doc/*.doc

     Now if we invoke _B_r_i_k with the command




Printed 0/0/0              Jul 8, 1989                          8






BRIK(1)             RISC/os Reference Manual              BRIK(1)



          brik -Gf wildfile

     it will read filespecs from "wildfile," expand wildcards in
     each filespec, and generate whole-file CRCs for all matching
     files.

     If you are checking whole-file CRCs with the -C option, you
     do not normally need to use the -f option.  When used with
     -C, the -f option introduces an additional level of file
     naming indirection. For example, the command

          brik -C crc.lst

     takes a list of CRCs and filenames from "crc.lst" and veri-
     fies them.  However, the command

          brik -Cf master.lst

     does not do the same thing.  Instead, it takes a list of
     files from "master.lst," looks inside each of _t_h_o_s_e files
     for a list of CRCs and filenames, and verifies them.

     As an example of the use of -Cf, consider this sequence:

          brik -Gb /bin/*.exe > exelist
          brik -Gb /bin/*.com > comlist
          brik -GT /doc/*.doc > doclist
          brik -G  /doc/*.man > manlist

     Now we have four files called "exelist," "comlist,"
     "doclist," and "manlist" containing whole-file CRCs of vari-
     ous types.  We can test the integrity of files listed in
     these in four separate commands like this:

          brik -C exelist
          brik -C comlist
          brik -C doclist
          brik -C manlist

     But we could also do this in a single step by first creating
     a file called "biglist" that contains the names of these
     four files:

          exelist
          comlist
          doclist
          manlist

     and then use -Cf thus:

          brik -Cf biglist




Printed 0/0/0              Jul 8, 1989                          9






BRIK(1)             RISC/os Reference Manual              BRIK(1)



     This causes _B_r_i_k to read filenames from "biglist," look
     inside each of those files ("exelist," "comlist," "doclist,"
     and "manlist") and check the CRCs found there.  A **IX exam-
     ple to do the same thing in a more compact way might be:

          cat exelist comlist doclist manlist | brik -Cf -

     The above examples are somewhat contrived, however.  We
     could also use the following command:

          brik -C exelist comlist doclist manlist


     SILENT VERSUS VERBOSE VERSUS QUIET

     _B_r_i_k accepts options -s, -q, and -v that control the degree
     of verbosity.

     Normally _B_r_i_k prints a message only if it detects an error.
     For example, if you give the command

          brik -c *.c *.h

     and _B_r_i_k finds that all _C_h_e_c_k_s_u_m: headers contain CRCs that
     match the calculated value, it prints nothing.

     The -v switch makes _B_r_i_k print a message for each file
     tested that contains the word "ok" if stored and calculated
     CRCs matched and "BAD" if they did not.

     In all messages reporting file CRCs, _B_r_i_k prints the actual
     CRC it calculated, or a row of question marks if it could
     not calculate one.  _B_r_i_k fails to calculate a CRC if it is
     trying to calculate a header-based CRC (commands -c and -g)
     but does not find a _C_h_e_c_k_s_u_m: header in a file.

     The -s switch tells _B_r_i_k to be silent.  This will cause
     nothing to be printed if _B_r_i_k does not find a _C_h_e_c_k_s_u_m
     header or if CRCs don't match.  However, the status code on
     exit is still set.  The -s option is useful for invoking
     _B_r_i_k from within a shell script (**IX) or a batch file (MS-
     DOS) and later testing the error code it returned when it
     exited.

     The -s switch does not suppress the error message printed if
     _B_r_i_k is given a filename and the file cannot be found.  For
     example, if the command

          brik -cs myfile

     is given but "myfile" does not exist, _B_r_i_k will print an
     error message even though the -s option was given.



Printed 0/0/0              Jul 8, 1989                         10






BRIK(1)             RISC/os Reference Manual              BRIK(1)



     The -q switch makes _B_r_i_k slightly quieter.  Its only effect
     is to suppress the introductory comments that are otherwise
     generated by the -C option.

     VAX/VMS BUGS

     o    Under VAX/VMS, file manipulation is unpredictable and
          the VAX/VMS C runtime library in particular is very
          unreliable.  One result is that under VAX/VMS, the -gW
          option will work only for stream-LF files, which are
          the only type of file that VAX/VMS seems to handle
          correctly.  Fortunately, the -c option will correctly
          work for VAX/VMS standard text files.

     o    The VAX/VMS implementation of _B_r_i_k simply ignores
          filenames that correspond to nonexistent files instead
          of giving an error message.  VMS users are invited to
          fix this bug (probably somewhere in the _n_e_x_t_f_i_l_e()
          function in the file _v_m_s._c) and send me the fix.

     o    To avoid annoying error messages, _B_r_i_k under VAX/VMS
          always exits with a status code of 1.

     o    Due to a problem in the VAX/VMS command interpreter, if
          any uppercase option characters are typed (e.g. -C, -G,
          -T), _B_r_i_k will not recognize them as uppercase unless
          they are enclosed in double quotes.  An example of a
          correct command under VAX/VMS:

            brik "-GT" *.*

          An example of a command that won't work:

            brik -GT *.*

     USAGE HINTS

     This section discusses some ways of using _B_r_i_k.

     -    _B_r_i_k is currently used to create and verify checksums
          of articles posted on the Usenet newsgroup
          comp.binaries.ibm.pc.  While reading Usenet news with
          _r_n, for example, you can verify the _C_h_e_c_k_s_u_m: header of
          such an article with the command:

            | brik -cv

          This feeds the current article to _B_r_i_k as standard
          input and asks it to verbosely verify the checksum.

     -    C and Pascal source files that are being distributed
          can be given their own _C_h_e_c_k_s_u_m: headers.  The



Printed 0/0/0              Jul 8, 1989                         11






BRIK(1)             RISC/os Reference Manual              BRIK(1)



          advantage of this over listing CRCs separately is that
          each file contains its checksum no matter where it
          goes.  The recipient can easily verify that each source
          file was received intact.  This is especially valuable
          when source files are being sent by electronic mail
          through an IBM mainframe-based network, such as BITNET,
          that can cause corruption of text files.

          Create the _C_h_e_c_k_s_u_m header with a text editor and ini-
          tialize its value with the command:

            brik -gW file ...

          The recipient can verify the checksum with the command:

            brik -cv file ...


     -    To keep track of any unexpected filesystem corruption
          or unauthorized changes to system files, _B_r_i_k can be
          used to create a list of checksums.  This should be
          done using the -b option (all binary checksums) or the
          -a option (use text or binary as appropriate).  Under
          **IX this can be done with a command like this one:

            find /bin /usr/bin /lib /usr/lib /usr/new \
             -type f -print | \
            grep -v '^/usr/bin/beta' | \
            grep -v '^/usr/new/lib/news' | \
            brik -Gbf - > crc.list

          This example uses _f_i_n_d to print the pathnames of cer-
          tain files, _g_r_e_p to filter out certain directory sub-
          trees, and then _B_r_i_k to print checksums of all selected
          files.  Periodically a background job can be run to
          compare the file list against current files and report
          any discrepancies:

            brik -C crc.lst | mail -s 'brik output' postmaster

          Under MS-DOS, create a list of checksums with the help
          of _S_t_u_f_f, a _f_i_n_d-like file finder program that is dis-
          tributed with _z_o_o 2.01:

            stuff /bin /msdos /turboc | brik -Gaf - > crc.list

          This is a simple mechanism that can be used to detect
          unexpected file changes caused by hardware problems or
          malicious programs such as viruses and worms.  Be
          warned, however, that since _B_r_i_k uses a published CRC
          algorithm, very clever deviant programs are possible
          that could change a file without affecting its CRC.



Printed 0/0/0              Jul 8, 1989                         12






BRIK(1)             RISC/os Reference Manual              BRIK(1)



          To avoid too many false alarms, only files that do not
          change much (such as system binaries) should be
          selected.

CHANGES
     Changes from version 1.0 are as follows.

     -    The CRC calculation has been recoded in 8086 assembly
          code suitable for Turbo C/MS-DOS.  As a result _B_r_i_k _2._0
          under MS-DOS is much faster than version 1.0.

     -    The new -a flag makes _B_r_i_k automatically determine for
          each file whether it is text or binary and calculate
          the CRC accordingly

     -    When _B_r_i_k is asked to calculate a text mode CRC but the
          file appears to be binary, it now does not print a
          warning message but instead adds a "*" suffix to the
          calculated CRC to indicate that the CRC may not be
          reliable.

     -    The new -H flag makes _B_r_i_k print the formatted _C_h_e_c_k_-
          _s_u_m: header to standard output.

     -    Detection of binary files is now more reliable under
          MS-DOS.  If a control Z character occurs near the
          beginning of a binary file, _B_r_i_k will not be fooled by
          the apparent end-of-file but will in most cases reli-
          ably detect that the file is binary.

     -    The new -q flag suppresses the introductory comments
          from the output of the -G command.

BUGS
     _B_r_i_k is designed to work with computer systems that use the
     7-bit ASCII character set and 8-bit bytes with the eighth
     (parity) bit set to zero.

     _B_r_i_k has not been tested with computer systems that use
     ASCII characters with the eighth bit set or those that use
     EBCDIC characters.  Although it will calculate a CRC on such
     machines, the probability of this CRC being the same as the
     one calculated on machines that use 7-bit ASCII is approxi-
     mately 0.00000000023.

DIAGNOSTICS
     Error messages are intended to be self-explanatory.

     The exit status returned is 1 if _B_r_i_k was invoked with
     incorrect arguments, else it is the number of files found
     with missing or invalid CRCs, but not greater than an
     operating-system-dependent maximum value.



Printed 0/0/0              Jul 8, 1989                         13






BRIK(1)             RISC/os Reference Manual              BRIK(1)



COPYRIGHT
     Both this documentation and _B_r_i_k are Copyright 1989 Rahul
     Dhesi, all rights reserved.  Permission is granted to copy,
     use, and distribute for any commercial or noncommercial pur-
     pose in accordance with the requirements of version 1.0 of
     the _G_N_U _G_e_n_e_r_a_l _P_u_b_l_i_c _l_i_c_e_n_s_e.

     Note:  This software has not been endorsed by the Free
     Software Foundation, the creator of the GNU license, and I
     am not affiliated with that organization.

AUTHOR
     Rahul Dhesi
     UUCP: {iuvax,pur-ee}!bsu-cs!dhesi
     Internet: dhesi@bsu-cs.bsu.edu








































Printed 0/0/0              Jul 8, 1989                         14



