Xxhash: 0.7.3 weird silent execution

Created on 24 Mar 2020  路  17Comments  路  Source: Cyan4973/xxHash

Why does xxhsum 0.7.3 sse2 (crc32 xxhsum.exe 80f61578) execute silently on Windows 7 x64?

$ xxhsum
$ xxhsum -h
$ xxhsum --help
$ xxhsum /?

Previous version 0.7.2 at least throws as follows

$ xxhsum
Wrong parameters
D:\xxhsum.exe 0.7.2 (64-bits x86_64 + SSE2 little endian), GCC 9.2.0, by Yann Collet
Usage :
      D:\xxhsum.exe [arg] [filenames]
When no filename provided, or - provided : use stdin as input
Arguments :
 -H# : hash selection : 0=32bits, 1=64bits, 2=128bits (default: 1)
 -c  : read xxHash sums from the [filenames] and check them
 -h  : help

All 17 comments

Hmm, what terminal and shell are you using?

On Linux, the binary produces the expected help message.
So I guess it's a Windows specific issue.

Of course it is a Windows issue鈥othing changed for Linux. :smile:

I am guessing it has something to do with WriteConsoleW.

@sergeevabc does printing a checksum work? Because that prints to stdout instead of stderr.

$ ver
Microsoft Windows [Version 6.1.7601]

$ head -c 100 /dev/zero | xxhsum 
17bb1103c92c502f  stdin

$ head -c 100 /dev/zero zeroes.txt && xxhsum zeroes.txt
17bb1103c92c502f  100.txt

By the way, those intermediate 0.7.3 x64 binaries output help as expected.

Ok, so that means it has been fixed, since that was a newer version.

@Cyan4973, it seems you forgot to roll a release after tremendous @easyaspi314鈥檚 Unicode efforts.

Well don't roll a release yet, haven't yet fixed #341 :smile:

But yeah, the 0.7.3 solution was a little half-(moji?)baked, it was codepage-dependent and crashed on XP.

Of course, Unicode on Windows is also half-baked. Thankfully, 1903 is finally providing sane UTF-8, but it is only beta and hasn't been backported.

Also consider polishing help a bit. Created #345.

We did improve the help messages a bit in 0.7.3.

@easyaspi314, I saw it and did not like either. Consider the proposal above.

Well this is what GNU md5sum outputs:

Usage: md5sum [OPTION]... [FILE]...
Print or check MD5 (128-bit) checksums.

With no FILE, or when FILE is -, read standard input.

  -b, --binary         read in binary mode
  -c, --check          read MD5 sums from the FILEs and check them
      --tag            create a BSD-style checksum
  -t, --text           read in text mode (default)
  -z, --zero           end each output line with NUL, not newline,
                       and disable file name escaping

The following five options are useful only when verifying checksums:
      --ignore-missing  don't fail or report status for missing files
      --quiet          don't print OK for each successfully verified file
      --status         don't output anything, status code shows success
      --strict         exit non-zero for improperly formatted checksum lines
  -w, --warn           warn about improperly formatted checksum lines

      --help     display this help and exit
      --version  output version information and exit

The sums are computed as described in RFC 1321.  When checking, the input
should be a former output of this program.  The default mode is to print a
line with checksum, a space, a character indicating input mode ('*' for binary,
' ' for text or where binary is insignificant), and name for each FILE.

GNU coreutils online help: <https://www.gnu.org/software/coreutils/>
Report any translation bugs to <https://translationproject.org/team/>
Full documentation <https://www.gnu.org/software/coreutils/md5sum>
or available locally via: info '(coreutils) md5sum invocation'

BTW, this should be fixed: the default behavior of running md5sum without any args is to read from stdin.

When no filename provided or when '-' is provided, uses stdin as input.

new patch from @easyaspi314 merged into dev branch.

Could you be so kind to release some minor/fix release with this patch included?
Silent execution with no ability to get a help page for already 2 months drives me crazy.

>tfw you are too afraid to install msys2 so you torture yourself for 2 months

I mean, I think it's fine if we do a v0.7.4 release before we decide the best way to handle #358, right @Cyan4973?

When there is no pressure due to some kind of security liability, I prefer to produce meaningful releases, with significant improvements helping to justify user's cost of swapping.

358 is definitely part of this picture, and I would prefer to have it onboard for v0.7.4.

For the request in this thread, one could generate a Windows binary from dev branch source code, and make it available to download. It could even be attached to v0.7.3 release note, if that helps.

Was this page helpful?
0 / 5 - 0 ratings