Re: Enhancement Request for sha256sum - output only the SHA-256 hash alone

[Kaz Kylheku (Coreutils)]

On 2020-07-17 14:33, Pádraig Brady wrote:
> On 17/07/2020 15:21, jens.archlinux jens wrote:
> > Hello,
> >
> > propose to add a new option for sha256sum to output only the SHA-256 
> > hash
> > alone, without a trailing file name and without a trailing newline.
> >
> > (This would make sense for one input file only).
> >
> > It would make shell scripts that use sha256sum much simpler. Currently 
> > it
> > is necessary to split the output of sha256sum to obtain the hash, 
> > which
> > usually requires an additional command / Unix process.
>
> This is one of those trade-offs.
> I'd be 60:40 against adding such an option,
> because it's so easy to implement with cut(1):

Can I muse about checksum utility design?

Someone once, who didn't understand Unix utility design principles,
had the dumb idea of polluting the output of a checksumming utility
with extraneous information. Somehow that became a meme for authors
of new checksumming utilities, though not so rigid a meme that they
would actually make those outputs compatible with their predecessors.

Maybe it was the same person who thought it's a good idea for "dd"
to output, by default, cruft like:

  0+0 records in
  0+0 records out
  0 bytes (0 B) copied, 0.726321 s, 0.0 kB/s

Did that person ever work at Microsoft on MS-DOS? It's suspiciously
reminiscent of:

  C:\Users\kaz>copy foo.txt bar.txt
          1 file(s) copied.

(Thank you; I would never be able to guess that one file was
copied from the fact that I specified one file, and the command's
termination status was successful).

I'm against adding the option for a this reason: the default
behavior of a checksum function should be to output nothing but
the checksum.

Note that the word "sum" is redundant in "sha256sum".

Thus there is an opportunity for a "sha256" utility which just outputs
nothing but the sum. That utility could bee sha256sum itself,
upon detecting that argv[0] ends in "sha256", though that is risque.

Also, that utility should perhaps calculate a continued sum when
given multiple arguments, and not individual sums. So that is to say:

   sha256 a b c
   sha256 <(cat a b c)

should be the same.

Now let's talk options. It should have two, -i and -f:

   sha256 -i <state> [ inputs ... ]

would calculate the hashes over the inputs, starting with the
specified state. The special <state> token of 0 (the ASCII
zero digit) would mean "the initial state". In the -i mode,
sha256 would output a string (in an unspecified, opaque format,
perhaps inspired by "stty -g") which encodes the newly updated
state. The string should have no quoting or escaping issues
for shell programming.

The output of sha256 -i would be suitable as an argument to
the -i option of a new command, to continue the hashing operation
over additional inputs. It would also be suitable as an argument
to -f, so that:

   sha256 -f <state> [ inputs ... ]

would process inputs (if any) just like sha256 -i <state>, and then
do the hash finalization, and output not another state cookie, but
the final hash.

Thus, the output of

   sha256 a b c

could also be obtained using:

   st=$(sha256 -i 0)
   st=$(sha256 -i $st a)
   st=$(sha256 -i $st b)
   st=$(sha256 -i $st c)
   sha256 -f $st

or:

   st=$(sha256 -i 0 a b c)
   sha256 -f $st

or:

   st=$(sha256 -i 0)
   sha256 -f $st a b c

or, "point-free" application:

   sha256 -f $(sha256 -i 0 a b c)

etc.

I would add one more option: -s (literal string, not file name).

Whenever one or more -s options are present, their argument values
are pulled into the hash, in the order they appear, before any
files. Thus:

   $ sha256 -s coreutils
   3993c379c029014a9c4b2adf5d23397b3c7421467a0cb3575ff925bb6f6329b0

   $ sha256 -s core -s utils
   3993c379c029014a9c4b2adf5d23397b3c7421467a0cb3575ff925bb6f6329b0

   $ sha256 -f $(sha256 -i 0 -s core -s utils)
   3993c379c029014a9c4b2adf5d23397b3c7421467a0cb3575ff925bb6f6329b0


-i and -f are mutually exclusive, and must precede any -s options.