cksum: Quick CRC Checksums in CI
cksum prints a CRC checksum, the byte count, and the file name, for quick non-cryptographic change detection.
cksum is a fast fingerprint for "did this file change" checks. It is not cryptographic, so use it for change detection, not integrity against tampering.
What it does
cksum computes a CRC of the file and prints CRC BYTES FILENAME. It is defined by POSIX, so the classic CRC is stable across systems. GNU coreutils 9+ added -a to select other algorithms (crc32b, sha256, blake2b), but the default remains the POSIX CRC. Use it to detect change cheaply, not to verify against attackers.
Common usage
cksum build/app.js
# e.g. 4294967295 10240 build/app.js
# compare against a stored value
old=$(cat app.cksum); new=$(cksum build/app.js | cut -d' ' -f1-2)
[ "$old" = "$new" ] || echo "changed"
# GNU coreutils 9+: pick an algorithm
cksum -a sha256 file.binOptions
| Flag / field | What it does |
|---|---|
| (default) | POSIX CRC, then a space, byte count, filename |
| -a <algo> | coreutils 9+: crc, crc32b, sha256, blake2b, etc. |
| --untagged | coreutils 9+: print sum in the classic bare style |
| field 1 | The CRC value |
| field 2 | The byte count |
In CI
Use cksum to short-circuit expensive steps: store cksum inputs from the last run and skip a rebuild if the CRC and byte count are unchanged. For any security-relevant verification (a downloaded release), use sha256sum instead, since CRC collisions are trivial to construct.
Common errors in CI
A CRC that differs between two machines usually means one is not GNU cksum (BusyBox and BSD produce the same POSIX CRC, but -a selection differs). Do not compare cksum output against a sha256sum value; they are different algorithms. On coreutils 9+, the default is still the POSIX CRC, but scripts that assumed -a support break on older systems.