Why do I get different results from Mac's shasum than from other shasum calculators?

Question

I'm entering:

appletree:~ somename$ shasum -a 512 <<< test

And the output is:

0e3e75234abc68f4378a86b3f4b32a198ba301845b0cd6e50106e874345700cc6663a86c1ea125dc5e92be17c98f9a0f85ca9d5f595db2012f7cc3571945c123  -

Then I go to some online hash generators and enter "test" too. Their answers are:

http://hashgenerator.de/:

ee26b0dd4af7e749aa1a8ee3c10ae9923f618980772e473f8819a5d4940e0db27ac185f8a0e1d5f84f88bc887fd67b143732c304cc5fa9ad8e6f57f50028a8ff

http://passwordsgenerator.net/sha512-hash-generator/:

EE26B0DD4AF7E749AA1A8EE3C10AE9923F618980772E473F8819A5D4940E0DB27AC185F8A0E1D5F84F88BC887FD67B143732C304CC5FA9AD8E6F57F50028A8FF

So the online generators agree. What am I missing in the Mac console command?

I was reading the man pages. I see it's implemented using a Perl library. However, I think sha512 would be a unique designation, so I have to dig deeper.

---

There seems to be a duplicate question: Why is my command-line hash different from online MD5 hash results?. While the other question is in the same context, which is unexpected whitespace, it emerges from a different situation.

• <<< is a here string, and there is a design choice for how here strings add newline.
• echo 'bla' | means piping, which invokes sub shells, and also has arguments for how to handle newline. Here it seems you have to consider the shell version.

Solution 1

The input to the shasum invocation in the question is test\n (with a newline), not test.

If you give test with no newline to shasum you’ll get the same output as the online tools cited:

$ echo -n "test" | shasum -a 512
ee26b0dd4af7e749aa1a8ee3c10ae9923f618980772e473f8819a5d4940e0db27ac185f8a0e1d5f84f88bc887fd67b143732c304cc5fa9ad8e6f57f50028a8ff  -

By the way, I think there’s nothing MacOS-specific about the shasum found on MacOS; I think shasum is part of the standard Perl distro — installed along with, e.g., the perl command.

Solution 2

Try this:

hexdump -C <<< test

Knowing Unix shells, you're probably getting an unwanted 0x0a at the end of that string.

Comments

[WeSee]

od will label control characters and make the more apparent; try: od -t a -t x1 <<< test (never really used hexdump),

[Joshua Pinter]

You the real MVP. Had me stumped for quite awhile, assuming that I was doing something clearly wrong. Turns out echo is just doing some sneaky newline business.