14

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.
Improve this question
6
  • Thanks a lot to sideshowbarker and Spiff. Whitespace strikes again ^^ ^^
    – peter_the_oak
    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.
    – peter_the_oak
    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

Reset to default
34

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.

Improve this answer
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.
    – Joshua Pinter
    Nov 30, 2021 at 20:17
19

Try this:

hexdump -C <<< test

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

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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.