sum (Unix)

sum is a core utility available on Unix and Unix-like operating systems. This utility outputs the checksum of each argument file, as well as the number of blocks they take on disk.[1]

sum
Original author(s)Ken Thompson
Developer(s)AT&T Bell Laboratories
Initial releaseNovember 3, 1971 (1971-11-03)
Operating systemUnix, Unix-like, Inferno
TypeCommand
Licensecoreutils: GPLv3+

Overview

There is a GNU utility written by Kayvan Aghaiepour and David MacKenzie and distributed with the Unix- and Linux-based operating systems.

According to the manual page,[1] sum uses two different algorithms for calculating the checksum and blocks, the SYSV checksum algorithm and the BSD checksum (default) algorithm. Switching between the two algorithms is done via command line options.

The algorithms implemented in this program are less sensitive than more modern checksum methods; the SYSV algorithm does not even depend on the order of the data. The GNU manual page states: "sum is provided for compatibility; the cksum program is preferable in new applications".

Syntax

The sum utility is invoked from the command line according to the following syntax:

sum [OPTION]... [FILE]...

with the possible option parameters being:

  • -r
  • -s, --sysv
  • --help
    • display the help screen and exit
  • --version
    • output version information and exit

When no file parameter is given, or when FILE is -, the standard input is used as input file.

gollark: Tape Shuffler would be okay with it, Tape Jockey doesn't have the same old-format parsing fallbacks and its JSON handling likely won't like trailing nuls, no idea what tako's program thinks.
gollark: Although I think some parsers might *technically* be okay with you reserving 8190 bytes for metadata but then ending it with a null byte early, and handle the offsets accordingly, I would not rely on it.
gollark: Probably. The main issue I can see is that you would have to rewrite the entire metadata block on changes, because start/end in XTMF are offsets from the metadata region's end.
gollark: I thought about that, but:- strings in a binary format will be about the same length- integers will have some space saving, but I don't think it's very significant- it would, in a custom one, be harder to represent complex objects and stuff, which some extensions may be use- you could get some savings by removing strings like "title" which XTMF repeats a lot, but at the cost of it no longer being self-describing, making extensions harder and making debugging more annoying- I am not convinced that metadata size is a significant issue
gollark: I mean, "XTMF with CBOR/msgpack and compression" was being considered as a hypothetical "XTMF2", but I'd definitely want something, well, self-describing.

See also

References
  1. sum(1) — manual pages from GNU coreutils
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.