有沒有人知道在以下兩種情況下輸出差異的原因？在Windows和OS X實現之間PowerShell別名'ls'和'dir'的行爲不同的原因是什麼
別名ls的輸出不同於OSX上的別名dir的輸出。在PowerShell幫助所示Help Get-Content -Examples一個例子：
dir ./*.txt | foreach {Get-Content $_ -Head 1; Get-Content $_ -Tail 1}
作品每例子。但是，如果dir替換ls：返回
ls ./*.txt | foreach {Get-Content $_ -Head 1; Get-Content $_ -Tail 1}
錯誤：
LS：./*.txt：沒有這樣的文件或目錄
上述兩種情況下在Windows 10上的PowerShell v5中給出相同的結果。
這個觀察是一個錯誤嗎？
您似乎在調用命令/bin/ls（/usr/bin/ls？）而不是PowerShell別名ls，即使別名應優先於外部命令。驗證別名實際上是定義：
Get-Alias -Name ls
內置命名爲標準Unix工具被有意留出的跨平臺版本的僅Windows版的別名，以免陰影（覆蓋）它們。
注：這是真正的作爲PowerShell核心V6.0.0-alpha.10的，但是這樣的設計決策已經引起了爭議 - 找到討論here。
一個值得注意的錯誤是，PowerShell在調用外部實用程序時不執行通配符，因此像ls *.txt這樣的東西在Bash中不起作用，例如。
因此，別名ls，內置於Windows的本地版本，是不是內置到Linux & MacOS的版本，因爲標準的效用/bin/ls應優先那裏。
相比之下，dir - 由於未與任何標準的Unix工具名稱發生衝突 - 是一個內置的別名所有版本（並指Get-ChildItem，因爲在Windows上）。
當PowerShell的是僅Windows，添加別名，如ls（爲Get-ChildItem）和cat（用於Get-Content）是一個點頭的人從Unix背景的到來。
在Windows上，這些命令名稱沒有預定義的含義，但在類Unix系統中，它們會影響標準實用程序（CLI），導致潛在的意外行爲。
的安全，可移植的方法是堅持：使用完整cmdlet名稱，而不是別名
ls或dir）。PowerShell有命名約定用於從cmdlet名稱衍生的別名，映射每個批准動詞（如Get-和Copy-）至經批准的別名前綴（如g和cp） - 見https://msdn.microsoft.com/en-us/library/ms714428(v=vs.85).aspx。
如果不確定給定的命令名稱是指什麼，請使用Get-Command <name>（或gcm <name>）。