cksum

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 standard (Ethernet). 4. The bit sequence is complemented and the result is the CRC. The standard input shall be used if no file operands are specified, and shall be used if a file operand is '-' and the implementation treats the '-' as meaning standard input. Otherwise, the standard input shall not be used. See the INPUT FILES section. Provide a default value for the internationalization variables that are unset or null. (See XBD Internationalization Variables for the precedence of internationalization variables used to determine the values of locale categories.) If set to a non-empty string value, override the values of all the other internationalization variables. Determine the locale that should be used to affect the format and contents of diagnostic messages written to standard error. [XSI) ] ![[Option Start]]( Determine the location of message catalogs for the processing of LC MESSAGES. ![[Option End]]( If no file operand was specified, the pathname and its leading shall be omitted. 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 POSIX.1-2017. Since this volume of POSIX.1-2017 does not specify the block size used when doing input, checksums of character special files need not process all of the data in those files. 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. 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. 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 single number (the checksum as printed) represents the s