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:
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
As far as I understand :
Using CMD :
return the same think as the following in PowerShell
That is to say :
@Mofi seems to be right, you can reproduce the CMD result in Powershell using :
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 usegit 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 longFor 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# :
The result in a PowerShell console is :
The result in a CMD console is :
QED ?