md5sum: md5sum from coreutils-8.25-2.oc00.pentium4 cannot read its own .md5 files

[Lewis Rosenthal]

Creating an md5 checksum via:

[j:\]md5sum bluelion-0.0-en.iso > bluelion-0.0-en.md5

yields the following upon attempting to read the file:

[j:\]md5sum -c bluelion-0.0-en.md5
md5sum.exe: 'bluelion-0.0-en.iso'$'\r': No such file or directory
: FAILED open or read
md5sum.exe: WARNING: 1 listed file could not be read

We don't like the end of the file.

[Lewis Rosenthal]

Obviously, running dos2unix against the file makes it usable for md5sum.

[Silvan Scherrer]

this has nothing to do with it's own md5 files. as redirecting is out of scope of md5sum. It has to do that it should treat inputfiles with crlf and cr the same.
This is just a note to myself, as the original description is not 100% accurate.

[Silvan Scherrer]

even old 8.6 md5sum does't work. So not a porting regression.

[Lewis Rosenthal]

Agreed that the description is not fully accurate. The issue is with not (properly) ignoring DOS line endings, as you say, Silvan.

I suspect that this is not the only ported app which will behave this way. Whether the fix lies in kLIBC I do not know. I do know, however, that it should not be necessary to run yet another utility to strip the line endings.

I tested this under dash, and got the same result when redirecting the output as I did under 4OS2.

For now, the workaround is to pipe such redirection through dos2unix first, and then save the resulting file, as in:

[j:\]md5sum bluelion-0.0-en.iso | dos2unix > bluelion-0.0-en.md5

[Silvan Scherrer]

this issue is fixed with latest coreutils. I hope the change will not break too many other coreutils binaries. But then we have to fix one by one.