Xxhash: bsd output style

[grylem]

Hello
please add options for bsd otput style for calc and checking like
XXHASH32 (filename) sum
XXHASH64 (filename) sum
XXHASH128 (filename) sum
Thanks.

[easyaspi314]

This isn't a bad idea.
The only potential issue is that older versions of xxhsum wouldn't be able to read it.
For the reference, it would go like this

xxh128 (checksum.xxh128) = 9eb7a54d24dbf6a2eb9f7ce7a1853cd0

Note that coreutils provides the --tag option which switches to the BSD format.

[Cyan4973]

Preserving consistency with coreutils is important.
Adding support for --tag format is a good idea.

[grylem]

sorry i made a mistake in the title should be "bsd output style".

[Cyan4973]

Adding a new output mode will be easy.

What will be more difficult is to add a matching consumption mode.
xxhsum -c must read files produced by xxhsum, to control listed checksums.
For consistency, it will also have to read files produced by xxhsum --tag.

This will cost code, complexity and time.

[easyaspi314]

Well if we are going to match coreutils, we are also missing the backslash modifier.

If the first non-space character is a backslash, it will escape \n and \\.

So

$ export FILENAME=$'foo\n\\bar.txt'
$ echo "$FILENAME" > "$FILENAME"
$ md5sum "$FILENAME"
\dc7fd66c4fc94c46b7c91d95c2c30914  foo\n\\bar.txt
$ md5sum --tag "$FILENAME"
\MD5 (foo\n\\bar.txt) = dc7fd66c4fc94c46b7c91d95c2c30914
$ xxhsum "$FILENAME"
cbf4f722b723ac65  foo
\bar.txt

If we really want to do that, it will be a pain unless we just copy from coreutils.

Note that Busybox and Toybox's implementation acts like xxhsum.

[Cyan4973]

That's probably a different topic, not specifically related to the --tag option.

[grylem]

RHash can work with both types of output format - BSD and md5sum. For calculating and checking.

[baryluk]

I personally think that BSD format is silly (plus hard handling of special characters), compared to GNU format, but I wouldn't object having --tag for compatibility and drop-in replacement of existing utils. But that also probably requires adding support in xxhsum -c to work robustly (including mixed hashes, and tag vs non-tag formats).

[easyaspi314]

Yeah the BSD format is nice to look at, but painful to parse.

In a perfect world, you could do this:

int hash_type;
char *fname_buf = malloc(strlen(line)+1);
char hash_buf[17];
if (sscanf(line, "XXH%d (%[^)]) = %16s\n", &hash_type, fname_buf, hash_buf) == 3) {
    ...
}

But you would actually need to approach it from both sides, as the filename can contain parentheses and equal signs.

[sergeevabc]

TurboSFV outputs sums.xxh much like md5sum does, as follows

$ cat sums.xxh
44981e068bb9c260 *a.txt 
dfbd61e5cdfd8f86 *b.txt 

but alas it is not recognized by XXHSum

$ xxhsum-x64-mingw-w64 -c sums.xxh
sums.xxh: no properly formatted xxHash checksum lines found  

removing asterisk does not help, however replacing asterisk with space does.

$ cat sums.xxh
44981e068bb9c260  a.txt
dfbd61e5cdfd8f86  b.txt

$ xxhsum-x64-mingw-w64 -c sums.xxh
a.txt: OK 
b.txt: OK

In the end I wonder whether XXHSum could be a little more flexible about format, not that rigid.

[Cyan4973]

Well, there's no guarantee that xxhsum will support any other display format independently decided by another utility.

In this case though, the difference seems small, so it should be easy to become compatible with it.

[Cyan4973]

I can probably add a --tag BSD-style output to xxhsum,
but it's much less clear if I can _read_ it (with check command -c)
while keeping this development under reasonable time-constrained budget.

I'm wondering if having just the first part (output only) makes sense.

[Cyan4973]

--tag will be a hidden option for next release.
I have no time to add a reader (-c) for next release, so the option will remain undocumented, until the corresponding -c check option is developed.

[Cyan4973]

With @WayneD 's #420, also offering --check ability for --tag format,
the feature is now completed.