2

I get the following in PowerShell:

D:\> echo "Apple Pie" | git hash-object --stdin
157cb7be4778a9cfad23b6fb514e364522167053

D:\> "Apple Pie" | git hash-object --stdin
157cb7be4778a9cfad23b6fb514e364522167053

but in CMD.exe:

C:\>echo "Apple Pie" | git hash-object --stdin
bb3918d5053fea31fc9a58fae1e5bdeabe3ec647

In a PluralSight video, I see a different value from what seems to be a Mac console:

enter image description here

What is the exact value piped from echo in each case?

I get a different hash if I go to one of those online SHA1 generators and enter the string Apple Pie. From those I get:

8d69b7365f59237d3fb052c1f2f15ea33457fe51

Old Geezer
  • 10,411
  • 21
  • 87
  • 156
  • 2
    Internal command __ECHO__ of `cmd.exe` outputs also the double quotes and the space character left to redirection operator `|`. I suppose without testing as `git` not installed that the hash will be the same as in PowerShell on using `echo Apple Pie| git hash-object --stdin` to create the hash for the string `Apple Pie`. If it is still different than because of `cmd` command __ECHO__ outputs also the newline characters after the string `Apple Pie`. – Mofi Apr 11 '20 at 07:57
  • You are right! `echo Apple Pie|git hash-object --stdin` produces `157cb7b..`, same as PowerShell 'echo "Apple Pie"`. – Old Geezer Apr 11 '20 at 08:36
  • And Powershell `echo '"Apple Pie" ' | git hash-object --stdin` produces `bb39...`, same as CMD `echo "Apple Pie" | ...`. – Old Geezer Apr 11 '20 at 08:46
  • `echo "Apple Pie" | where {$_length -eq 9}` shows that the string does not have `CRLF` added, but if redirected to a file, there is `CRLF`. – Old Geezer Apr 11 '20 at 08:50

1 Answers1

2

As far as I understand :

Using CMD :

echo Apple Pie|git hash-object --stdin

return the same think as the following in PowerShell 

"Apple Pie" | git hash-object --stdin

That is to say : 

157cb7be4778a9cfad23b6fb514e364522167053

@Mofi seems to be right, you can reproduce the CMD result in Powershell using :

'"Apple Pie" ' | git hash-object --stdin

To explain the Mac OS one : To obtain 157cb7be4778a9cfad23b6fb514e364522167053 the real list of chars that is hashed is 'Apple Pie\r\n' (with carage return line feed), in Mac or linux like command line it's 'Apple Pie\r'.

If you want to test this : put 'Apple Pie' in a text file with a cariage return and save it as a Windows text style (CR+LF), and use git hash-object yourfile.txt. Then save it in Linux style (LF) and test again, you will find your two hashes.

The part about \r\n.

"Apple Pie" | where {$_.length -eq 9} shows that the string is exactly 9 characters long

For me it's because in your case the pipe is between two PowerShell parts, the pipe transmit an object. When the pipe is between PowerShell and an external EXE then the \r\n are added. Here is a way to test that with a small exe file written in C# :

using System;
namespace C_Param
{
  class Program
  {
    static void Main(string[] args)
    {
      string line = Console.In.ReadToEnd();
      foreach (char character in line){
        Console.WriteLine(String.Format("{0:X2}", Convert.ToByte(character)));
      }
    }
  }
}

The result in a PowerShell console is :

"Apple Pie" | .\C_Param.exe
41
70
70
6C
65
20
50
69
65
0D
0A

The result in a CMD console is :

echo "Apple Pie" | .\C_Param.exe
22
41
70
70
6C
65
20
50
69
65
22
20
0D
0A

QED ?

JPBlanc
  • 63,198
  • 12
  • 118
  • 155