0.8.2 outputs strange looking paths & hash when a Path is provided, in Windows

[therube]

xxhsum 0.8.2 outputs strange file path separator, & file hash results, on Windows

a file, provided with a path, & that path uses Windows style back slashes, outputs strange file path separators, & file hash results, on Windows

Win7 x64
0.8.2 x64

a [file], with no path provided,       xxhsum.exe xxhsum.exe
	is fine
a [file], provided with a path,        xxhsum.exe c:/bin/xxhsum.exe xxhsum.exe
	& the path uses forward slashes, is fine
a [file], provided with a path,        xxhsum.exe c:/bin\xxhsum.exe xxhsum.exe
	& the path uses mixed slashes, both forward & backwards,
	formats the forward slash fine, escapes, if you will, a backwards slash,
	& also prefaces the hash itself with a single backslash
a [file], provided with a path,        xxhsum.exe c:\bin\xxhsum.exe xxhsum.exe
	& the path uses Windows style backslashes,
	escapes, if you will, doubling the backwards slash,
	& also prefaces the hash itself with a single backslash
the last case, Windows style back slashes, also applies to (Windows) drag&drop
	& SendTo (a xxhsum.BAT batch file)

*Note: i did NOT check what happens with --check [a /quick/ check says --check is OK with things as they are. results do /look/ strange, but xxhsum is OK with it]

oddly, if you consider it odd, on a missing file, its' output message is "right", xxh.check.test:32: Could not open or read 'T:\TTT\PICS\SHOW\xxhshow00.png': No such file or directory.]

xxhsum.BAT:

@echo off
cat xxhsum.BAT
echo.

xxhsum.exe %*
pause

C:\BIN>xxhsum -V xxhsum 0.8.2 by Yann Collet compiled as 64-bit x86_64 autoVec little endian with GCC 13.1.0

C:\BIN>xxhsum xxhsum.exe 715c09679f0fbf99 xxhsum.exe

C:\BIN>xxhsum c:/bin/xxhsum.exe 715c09679f0fbf99 c:/bin/xxhsum.exe

C:\BIN>xxhsum c:/bin\xxhsum.exe \715c09679f0fbf99 c:/bin\xxhsum.exe

C:\BIN>xxhsum c:\bin\xxhsum.exe \715c09679f0fbf99 c:\bin\xxhsum.exe

C:\BIN>

@echo off cat xxhsum.BAT echo.

xxhsum.exe %* pause \715c09679f0fbf99 C:\BIN\xxhsum.exe Press any key to continue . . .

https://postimg.cc/WdgqPcNY

[t-mat]

Hi @therube, thanks for the report.

As for backslash (\), bd4ded9 has introduced md5sum style filename escape convention. When xxhsum needs to escape the filename, it outputs \ at the beginning of the line. And put \ for every character in the path which needs to be escaped.

See #695, #698, #699, #710 for details.

Therefore, from our point of view, it seems that your observations are intended outputs. But please let us know if this md5sum compatible output harms your environment / workflow.

My build & test log.

> cmd /c ver
Microsoft Windows [Version 10.0.22621.1992]    # Windows 11, 22H2

> cd C:\
> git clone https://github.com/Cyan4973/xxHash.git
> cd xxHash

> mkdir build
> cd build
> cmake ../cmake_unofficial -A x64
> cmake --build .
> cd Debug

> .\xxhsum.exe --version
xxhsum.exe 0.8.2 by Yann Collet
compiled as 64-bit x86_64 + SSE2 little endian with MSVC 19.36.32537.00

> .\xxhsum.exe C:/xxHash/README.md
9c871fd3096b631d  C:/xxHash/README.md

> .\xxhsum.exe C:\xxHash\README.md
\9c871fd3096b631d  C:\\xxHash\\README.md

[therube]

Ah, md5sum sure does do that, doesn't it. (Never saw that before.)

I'm fine with the path part, it just looks odd. To me though, & I had never seen anything like it before, the \ at the beginning of the line, at the hash, simply looks very strange.

Anyhow, now that I understand what's going on, I'm good.

Thank you.