> bs is one thing, ibs is another.

  bs=BYTES
         read and write up to BYTES bytes at a time (default: 512); over‐
         rides ibs and obs

As described, the script should have worked as is, and the problem is in the handling of the dd options. (But I didn't verify the accuracy of the description.)

▲ lesuorac 16 hours ago | parent [-]

Wonder if `\00` is handled different between them. Not sure how to run the rust version but my md5sum seems to care how many null bytes there are.

echo -e "\00" | md5sum 8f7cbbbe0e8f898a6fa93056b3de9c9c -

echo -e "\00\00" | md5sum a4dd23550d4586aee3b15d27b5cec433 -

	▲	hiccuphippo 14 hours ago \| parent \| next [-]
		Kind of off-topic, but those commands also add a newline character to the md5sums, giving unexpected results. I was trying it in a php interpreter and getting different values. Add -n to echo to avoid the new line.
	▲	zahlman 15 hours ago \| parent \| prev [-]
		> Wonder if `\00` is handled different between them. `dd` is for copying all the bytes of a source (unless you explicitly set a limit with the `count` option), regardless of whether they're zero. It's fundamentally not for null-terminated strings but arbitrary binary I/O. In fact, "copying from" /dev/zero is a common use case. It seems frankly implausible that the `dd` implementation is just stopping at a null byte; that would break a lot of tests and demonstrate a complete, fundamental misunderstanding of what's supposed to be implemented. > Not sure how to run the rust version but my md5sum seems to care how many null bytes there are. Yes, the md5 algorithm also fundamentally operates on and produces binary data; `md5sum` just converts the bytes to a hex dump at the end. The result you get is expected (edit: modulo hiccuphippo's correct observation), because the correct md5 sum changes with every byte of input, even if that byte has a zero value.