15

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.
6
  • Thanks a lot to sideshowbarker and Spiff. Whitespace strikes again ^^ ^^ Feb 18, 2017 at 10:01
  • 5
    Possible duplicate of md5: Why is my command-line hash different from online md5 hash results?
    – muru
    Feb 18, 2017 at 14:27
  • Note that a here string is intended to be exactly identical to a one-line here document, and a here document always ends with a newline.
    – chepner
    Feb 19, 2017 at 2:45
  • I am not new to shell, but here are some sophisticated details and news for which I'm grateful. So thanks for all the comments and answers. Feb 19, 2017 at 8:00
  • So we found that Mac's shasum command isn't any different. The issue was technically user error, and had to do with the data being passed, not the program. May I suggest renaming the question, to "Why do I get different results from Mac's shasum..." That way, people can instantly suspect a user-created issue. (Had I seen that, I might have been less inclined to check this question out right now. As currently titled, "What distribuishes the mac shell shasum from other shasum calculators?", I came here to learn about possible Mac-specific differences, which isn't what this actually ended up as
    – TOOGAM
    Feb 19, 2017 at 22:04

2 Answers 2

35

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.

1
  • 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. Nov 30, 2021 at 20:17
20

Try this:

hexdump -C <<< test

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

1
  • 2
    od will label control characters and make the more apparent; try: od -t a -t x1 <<< test (never really used hexdump), Feb 20, 2017 at 9:37

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .