cksum man page on Oracle

Man page or keyword search:  
man Server   33470 pages
apropos Keyword Search (all sections)
Output format
Oracle logo
[printable version]

CKSUM(1P)		   POSIX Programmer's Manual		     CKSUM(1P)

       This  manual  page is part of the POSIX Programmer's Manual.  The Linux
       implementation of this interface may differ (consult the	 corresponding
       Linux  manual page for details of Linux behavior), or the interface may
       not be implemented on Linux.

       cksum - write file checksums and sizes

       cksum [file ...]

       The cksum utility shall calculate and write to standard output a cyclic
       redundancy  check (CRC) for each input file, and also write to standard
       output the number of octets in each file. The CRC used is based on  the
       polynomial used for CRC error checking in the ISO/IEC 8802-3:1996 stan‐
       dard (Ethernet).

       The encoding for the CRC checksum is defined by the generating  polyno‐


       Mathematically,	the  CRC  value corresponding to a given file shall be
       defined by the following procedure:

	1. The n bits to be evaluated are considered to be the coefficients of
	   a  mod  2 polynomial M( x) of degree n-1. These n bits are the bits
	   from the file, with the most significant bit being the most signif‐
	   icant bit of the first octet of the file and the last bit being the
	   least significant bit of the last octet, padded with zero bits  (if
	   necessary) to achieve an integral number of octets, followed by one
	   or more octets representing the length of  the  file	 as  a	binary
	   value, least significant octet first. The smallest number of octets
	   capable of representing this integer shall be used.

	2. M( x) is multiplied by x**32 (that is, shifted left	32  bits)  and
	   divided  by G( x) using mod 2 division, producing a remainder R( x)
	   of degree <= 31.

	3. The coefficients of R( x) are considered to be a 32-bit sequence.

	4. The bit sequence is complemented and the result is the CRC.


       The following operand shall be supported:

       file   A pathname of a file to be checked.  If  no  file	 operands  are
	      specified, the standard input shall be used.

       The  standard  input  shall be used only if no file operands are speci‐
       fied. See the INPUT FILES section.

       The input files can be any file type.

       The following environment  variables  shall  affect  the	 execution  of

       LANG   Provide  a  default value for the internationalization variables
	      that are unset or null. (See  the	 Base  Definitions  volume  of
	      IEEE Std 1003.1-2001,  Section  8.2,  Internationalization Vari‐
	      ables for the precedence of internationalization variables  used
	      to determine the values of locale categories.)

       LC_ALL If  set  to a non-empty string value, override the values of all
	      the other internationalization variables.

	      Determine the locale for	the  interpretation  of	 sequences  of
	      bytes  of	 text  data as characters (for example, single-byte as
	      opposed to multi-byte characters in arguments).

	      Determine the locale that should be used to  affect  the	format
	      and contents of diagnostic messages written to standard error.

	      Determine the location of message catalogs for the processing of
	      LC_MESSAGES .


       For each file processed successfully, the cksum utility shall write  in
       the following format:

	      "%u %d %s\n", <checksum>, <# of octets>, <pathname>

       If  no file operand was specified, the pathname and its leading <space>
       shall be omitted.

       The standard error shall be used only for diagnostic messages.



       The following exit values shall be returned:

	0     All files were processed successfully.

       >0     An error occurred.


       The following sections are informative.

       The cksum utility is typically used to quickly compare a	 suspect  file
       against	a  trusted  version  of the same, such as to ensure that files
       transmitted over noisy media arrive intact.  However,  this  comparison
       cannot be considered cryptographically secure. The chances of a damaged
       file producing the same CRC  as	the  original  are  small;  deliberate
       deception is difficult, but probably not impossible.

       Although	 input files to cksum can be any type, the results need not be
       what would be expected on character special device  files  or  on  file
       types	not   described	  by   the   System   Interfaces   volume   of
       IEEE Std 1003.1-2001. Since this volume	of  IEEE Std 1003.1-2001  does
       not  specify the block size used when doing input, checksums of charac‐
       ter special files need not process all of the data in those files.

       The algorithm is expressed in terms of a bitstream divided into octets.
       If  a  file  is	transmitted between two systems and undergoes any data
       transformation (such as changing little-endian byte  ordering  to  big-
       endian),	 identical CRC values cannot be expected. Implementations per‐
       forming such transformations may extend cksum  to  handle  such	situa‐


       The following C-language program can be used as a model to describe the
       algorithm. It assumes that a char is one octet.	It also	 assumes  that
       the  entire  file  is available for one pass through the function. This
       was done for simplicity in demonstrating the algorithm, rather than  as
       an implementation model.

	      static unsigned long crctab[] = {
	      0x04c11db7, 0x09823b6e, 0x0d4326d9, 0x130476dc, 0x17c56b6b,
	      0x1a864db2, 0x1e475005, 0x2608edb8, 0x22c9f00f, 0x2f8ad6d6,
	      0x2b4bcb61, 0x350c9b64, 0x31cd86d3, 0x3c8ea00a, 0x384fbdbd,
	      0x4c11db70, 0x48d0c6c7, 0x4593e01e, 0x4152fda9, 0x5f15adac,
	      0x5bd4b01b, 0x569796c2, 0x52568b75, 0x6a1936c8, 0x6ed82b7f,
	      0x639b0da6, 0x675a1011, 0x791d4014, 0x7ddc5da3, 0x709f7b7a,
	      0x745e66cd, 0x9823b6e0, 0x9ce2ab57, 0x91a18d8e, 0x95609039,
	      0x8b27c03c, 0x8fe6dd8b, 0x82a5fb52, 0x8664e6e5, 0xbe2b5b58,
	      0xbaea46ef, 0xb7a96036, 0xb3687d81, 0xad2f2d84, 0xa9ee3033,
	      0xa4ad16ea, 0xa06c0b5d, 0xd4326d90, 0xd0f37027, 0xddb056fe,
	      0xd9714b49, 0xc7361b4c, 0xc3f706fb, 0xceb42022, 0xca753d95,
	      0xf23a8028, 0xf6fb9d9f, 0xfbb8bb46, 0xff79a6f1, 0xe13ef6f4,
	      0xe5ffeb43, 0xe8bccd9a, 0xec7dd02d, 0x34867077, 0x30476dc0,
	      0x3d044b19, 0x39c556ae, 0x278206ab, 0x23431b1c, 0x2e003dc5,
	      0x2ac12072, 0x128e9dcf, 0x164f8078, 0x1b0ca6a1, 0x1fcdbb16,
	      0x018aeb13, 0x054bf6a4, 0x0808d07d, 0x0cc9cdca, 0x7897ab07,
	      0x7c56b6b0, 0x71159069, 0x75d48dde, 0x6b93dddb, 0x6f52c06c,
	      0x6211e6b5, 0x66d0fb02, 0x5e9f46bf, 0x5a5e5b08, 0x571d7dd1,
	      0x53dc6066, 0x4d9b3063, 0x495a2dd4, 0x44190b0d, 0x40d816ba,
	      0xaca5c697, 0xa864db20, 0xa527fdf9, 0xa1e6e04e, 0xbfa1b04b,
	      0xbb60adfc, 0xb6238b25, 0xb2e29692, 0x8aad2b2f, 0x8e6c3698,
	      0x832f1041, 0x87ee0df6, 0x99a95df3, 0x9d684044, 0x902b669d,
	      0x94ea7b2a, 0xe0b41de7, 0xe4750050, 0xe9362689, 0xedf73b3e,
	      0xf3b06b3b, 0xf771768c, 0xfa325055, 0xfef34de2, 0xc6bcf05f,
	      0xc27dede8, 0xcf3ecb31, 0xcbffd686, 0xd5b88683, 0xd1799b34,
	      0xdc3abded, 0xd8fba05a, 0x690ce0ee, 0x6dcdfd59, 0x608edb80,
	      0x644fc637, 0x7a089632, 0x7ec98b85, 0x738aad5c, 0x774bb0eb,
	      0x4f040d56, 0x4bc510e1, 0x46863638, 0x42472b8f, 0x5c007b8a,
	      0x58c1663d, 0x558240e4, 0x51435d53, 0x251d3b9e, 0x21dc2629,
	      0x2c9f00f0, 0x285e1d47, 0x36194d42, 0x32d850f5, 0x3f9b762c,
	      0x3b5a6b9b, 0x0315d626, 0x07d4cb91, 0x0a97ed48, 0x0e56f0ff,
	      0x1011a0fa, 0x14d0bd4d, 0x19939b94, 0x1d528623, 0xf12f560e,
	      0xf5ee4bb9, 0xf8ad6d60, 0xfc6c70d7, 0xe22b20d2, 0xe6ea3d65,
	      0xeba91bbc, 0xef68060b, 0xd727bbb6, 0xd3e6a601, 0xdea580d8,
	      0xda649d6f, 0xc423cd6a, 0xc0e2d0dd, 0xcda1f604, 0xc960ebb3,
	      0xbd3e8d7e, 0xb9ff90c9, 0xb4bcb610, 0xb07daba7, 0xae3afba2,
	      0xaafbe615, 0xa7b8c0cc, 0xa379dd7b, 0x9b3660c6, 0x9ff77d71,
	      0x92b45ba8, 0x9675461f, 0x8832161a, 0x8cf30bad, 0x81b02d74,
	      0x857130c3, 0x5d8a9099, 0x594b8d2e, 0x5408abf7, 0x50c9b640,
	      0x4e8ee645, 0x4a4ffbf2, 0x470cdd2b, 0x43cdc09c, 0x7b827d21,
	      0x7f436096, 0x7200464f, 0x76c15bf8, 0x68860bfd, 0x6c47164a,
	      0x61043093, 0x65c52d24, 0x119b4be9, 0x155a565e, 0x18197087,
	      0x1cd86d30, 0x029f3d35, 0x065e2082, 0x0b1d065b, 0x0fdc1bec,
	      0x3793a651, 0x3352bbe6, 0x3e119d3f, 0x3ad08088, 0x2497d08d,
	      0x2056cd3a, 0x2d15ebe3, 0x29d4f654, 0xc5a92679, 0xc1683bce,
	      0xcc2b1d17, 0xc8ea00a0, 0xd6ad50a5, 0xd26c4d12, 0xdf2f6bcb,
	      0xdbee767c, 0xe3a1cbc1, 0xe760d676, 0xea23f0af, 0xeee2ed18,
	      0xf0a5bd1d, 0xf464a0aa, 0xf9278673, 0xfde69bc4, 0x89b8fd09,
	      0x8d79e0be, 0x803ac667, 0x84fbdbd0, 0x9abc8bd5, 0x9e7d9662,
	      0x933eb0bb, 0x97ffad0c, 0xafb010b1, 0xab710d06, 0xa6322bdf,
	      0xa2f33668, 0xbcb4666d, 0xb8757bda, 0xb5365d03, 0xb1f740b4

	      unsigned long memcrc(const unsigned char *b, size_t n)
	      /*  Input arguments:
	       *  const char*	b == byte sequence to checksum
	       *  size_t	n == length of sequence

		  register unsigned   i, c, s = 0;

		  for (i = n; i > 0; --i) {
		      c = (unsigned)(*b++);
		      s = (s << 8) ^ crctab[(s >> 24) ^ c];

		  /* Extend with the length of the string. */
		  while (n != 0) {
		      c = n & 0377;
		      n >>= 8;
		      s = (s << 8) ^ crctab[(s >> 24) ^ c];

		  return ~s;

       The  historical	practice  of  writing  the number of "blocks" has been
       changed to writing the number of octets, since the latter is  not  only
       more  useful,  but  also since historical implementations have not been
       consistent in defining what a "block" meant.  Octets are	 used  instead
       of bytes because bytes can differ in size between systems.

       The  algorithm used was selected to increase the operational robustness
       of cksum. Neither the System V nor  BSD	sum  algorithm	was  selected.
       Since  each of these was different and each was the default behavior on
       those systems, no realistic compromise was  available  if  either  were
       selected-some  set  of  historical applications would break. Therefore,
       the name was changed to cksum. Although	the  historical	 sum  commands
       will probably continue to be provided for many years, programs designed
       for portability across systems should use the new name.

       The algorithm selected is based on that used by the ISO/IEC 8802-3:1996
       standard	 (Ethernet)  for the frame check sequence field. The algorithm
       used does not match the technical definition of a checksum; the term is
       used for historical reasons.  The length of the file is included in the
       CRC calculation because this parallels inclusion of a length  field  by
       Ethernet	 in  its  CRC,	but also because it guards against inadvertent
       collisions between files that  begin  with  different  series  of  zero
       octets.	The  chance that two different files produce identical CRCs is
       much greater when their lengths are not considered. Keeping the	length
       and  the	 checksum  of  the file itself separate would yield a slightly
       more robust algorithm, but historical usage has always been that a sin‐
       gle  number  (the  checksum as printed) represents the signature of the
       file. It was decided that historical usage was the more important  con‐

       Early  proposals contained modifications to the Ethernet algorithm that
       involved extracting table values whenever an intermediate result became
       zero.  This  was demonstrated to be less robust than the current method
       and mathematically difficult to describe or justify.

       The calculation used is identical to that given in pseudo-code  in  the
       referenced Sarwate article. The pseudo-code rendition is:

	      X <- 0; Y <- 0;
	      for i <- m -1 step -1 until 0 do
		  T <- X(1) ^ A[i];
		  X(1) <- X(0); X(0) <- Y(1); Y(1) <- Y(0); Y(0) <- 0;
		  comment: f[T] and f'[T] denote the T-th words in the
		      table f and f' ;
		  X <- X ^ f[T]; Y <- Y ^ f'[T];

       The  pseudo-code	 is reproduced exactly as given; however, note that in
       the case of cksum, A[i] represents a byte of the file, the words X  and
       Y  are  treated as a single 32-bit value, and the tables f and f' are a
       single table containing 32-bit values.

       The referenced Sarwate article also discusses generating the table.



       Portions of this text are reprinted and reproduced in  electronic  form
       from IEEE Std 1003.1, 2003 Edition, Standard for Information Technology
       -- Portable Operating System Interface (POSIX),	The  Open  Group  Base
       Specifications  Issue  6,  Copyright  (C) 2001-2003 by the Institute of
       Electrical and Electronics Engineers, Inc and The Open  Group.  In  the
       event of any discrepancy between this version and the original IEEE and
       The Open Group Standard, the original IEEE and The Open Group  Standard
       is  the	referee document. The original Standard can be obtained online
       at .

IEEE/The Open Group		     2003			     CKSUM(1P)

List of man pages available for Oracle

Copyright (c) for man pages and the logo by the respective OS vendor.

For those who want to learn more, the polarhome community provides shell access and support.

[legal] [privacy] [GNU] [policy] [cookies] [netiquette] [sponsors] [FAQ]
Polarhome, production since 1999.
Member of Polarhome portal.
Based on Fawad Halim's script.
Vote for polarhome
Free Shell Accounts :: the biggest list on the net