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.
Community
  • 1
peter_the_oak
  • 439
  • 1
  • 4
  • 9
  • Thanks a lot to sideshowbarker and Spiff. Whitespace strikes again ^^ ^^ – peter_the_oak Feb 18 '17 at 10:01
  • 5
    Possible duplicate of [md5: Why is my command-line hash different from online md5 hash results?](http://superuser.com/questions/71554/md5-why-is-my-command-line-hash-different-from-online-md5-hash-results) – muru Feb 18 '17 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 '17 at 02: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 '17 at 08: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 '17 at 22:04
  • @TOOGAM: I agree, so I altered the title. Thanks a lot for the suggestion. – peter_the_oak Feb 21 '17 at 11:33

2 Answers2

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.

sideshowbarker
  • 2,658
  • 1
  • 13
  • 12
  • 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 '21 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.

Spiff
  • 101,729
  • 17
  • 175
  • 229
  • 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 '17 at 09:37