PowerShell 為什麼 alias 了 curl 就引起了如此大的爭議？

12-31

https://github.com/PowerShell/PowerShell/pull/1901
這裡已經炸開鍋了。
微軟從 Invoke-WebRequest 出現之初，就為它添加了 curl/wget aliases。PowerShell 開源後，curl 的作者專門跑來提交了一個 PR 刪除 Windows PowerShell 裡面已經有的 curl。

更新：根據樓下的一些答主所說，這個 curl 的 alias 只會在 Windows Powershell 上面有（非 posix powershell），那麼為什麼 cURL 的作者要等開源之後才來發 PR 刪除 Windows Powershell 的 curl alias？

其實核心問題在於 Invoke-WebRequest 功能不夠全……說真的我用原版 curl 比 iwr 多的多。

直接把功能做到和 curl.exe 等同並且加上強類型就不會有人能有意見了，你看有人噴 ls 的么？

首先，沒有強類型的 PS 那就沒意義了；然後，這個的根源是沒有和 native 進行強類型通訊的協議，我估計 @肖騏也在鬱悶這事，我開了 #1999 你們可以去頂。

這就導致，如果想要常見命令「類型化」，就必須要把常見命令重定向到自己實現的內部函數裡面（比如 ls），因為 shell 是給人操作的，如果常用的命令都沒有主打功能（強類型）的話，那我幹嘛不用 bash 或者 cmd。

再另外，curl 你要是去 build linux 版的 ps 是不會出現的，源碼裡面有寫。

不要被瞎帶節奏

你們用過周佳牌洗衣粉嗎？

那你們用過寫著雕牌其實是周佳牌的洗衣粉么？？

請看 PowerShell-RFC/RFC0007-Weak-Aliases.md at master · PowerShell/PowerShell-RFC · GitHub 這個裡面表明已經寫成的 PowerShell 腳本中用 curl 指代 Invoke-WebRequest 的情況大約是 cURL 的兩倍——雖然樣本量不大，因為 Windows 上使用 cURL/curl 的人本來就少。PowerShell team 正在考慮以更加兼容的方式解決該問題。

另一個有趣的事實是，badger 說「引入 curl 這個別名是 breaking change」可能是不準確的——2009 年我們有 PowerShell 別名 curl，2011 年 cURL 的 Windows 版本才存在。——來自 @到處挖坑蔣玉成

更正：上面這個關於時間順序的問題是不對的。

——————

我剛剛重新讀了最初的問題，發現題主沒有搞懂 Invoke-WebRequest、cURL 和 curl（PowerShell 別名）之間的關係……

cURL 是一個開源工具，用於發起網路請求，它的可運行文件名是 curl 或 curl.exe。

Invoke-WebRequest 是一個 PowerShell cmdlet，用戶發起網路請求。

curl 也是 Microsoft 在 Invoke-WebRequest 出現之初為它定製的一個別名。

題主一開始似乎以為 Invoke-WebRequest 是用 cURL 實現的，這是不對的。

問題的焦點在於是否應該從 Windows PowerShell 中移除 curl 作為 Invoke-WebRequest 的別名。

——————

疑難解答。

問：為什麼我認為不應該在 Windows PowerShell 的腳本（.ps1 等）里刪除這兩個別名？

答：出於兼容性的考慮，不應該 break 已經寫好的代碼，況且 curl/wget 作為別名是曾經記載在文檔上的。更多地，我支持建立一種新的規範，要求所有的腳本必須寫全名而不是別名。參考 Set-StrictMode for better writing style · Issue #2000 · PowerShell/PowerShell · GitHub

問：為什麼我不要求 PowerShell for *nix 自動包含這兩個別名？

答：PowerShell 開源之前，沒有「兼容 PowerShell for *nix」的概念，大家寫出來的腳本兼容的是 Windows PowerShell，因此這個（跨平台）不同之處不會有兼容性問題——因為一開始就沒有想要有這個兼容性。

問：我對這兩個別名的態度？

答：我覺得這兩個別名很蠢——對於一個已經知道 curl/wget 而完全不了解 PS 的人是一種疑惑。我從來不用（互動式和腳本都不用）這兩個別名，對於 Invoke-WebRequest，我喜歡的別名是 poke（我自己加的）。但是，在不構成商標侵權的情況下，我堅決支持在已經有的平台和擴展名的腳本裡面繼續支持這兩個別名，維持優良的兼容性傳統。我支持在 PowerShell for *nix 中不支持這兩個別名。

問：（這裡應該有一個問題，但是我不知道怎麼問）

答：書寫跨平台、兼容性好的腳本的必要條件是，使用全名而不是別名。別名是為了方便交互使用的。

——————

我擔心的事情終於發生了。

根據 Belleve，這些別名在 PowerShell for *nix 上並不存在。也就是說，這個 PR 除了 break Windows 上現有的代碼沒法帶來什麼實際價值。

這幫人根本沒意識到 curl 加進來不是 breaking change——在 Invoke-WebRequest 剛開始有的時候就有 curl wget 別名。現在幹掉 curl 會導致一大批不良好書寫（但仍然按照文檔書寫，因此應當兼容）的代碼壞掉。而且在 PS 中要 invoke 一個 exe 應該用路徑語法。為什麼這些人熱愛 break 已經存在的東西？

請使用 cmd 或者 curl.exe，或者 .curl，或者 Start-Process curl，而不是使用 curl。這不但有書寫習慣上的好處——在 PowerShell 裡面一個光桿名字就是指調用內部命令——而且可以避免二進位重定向和 PowerShell 面向對象重定向/管道的不兼容。跨平台腳本更不要用別名。

利益相關：Windows 使用者，Windows PowerShell 使用者，從來不寫 curl/wget 來調用 Invoke-WebRequest 的人，在腳本里只用全名的人，支持兼容性的人。

補充：章程提到在那個下面的討論裡面已經有提出 curl 和 wget 不是 constant alias，可以被刪除。

補充 2：我認為可以設置一個新版本的嚴格模式。新版本要求其中的命令調用必須符合良好的寫作規範——不能使用別名，除非你顯式設置。更多過於這個提議的請到這裡 Set-StrictMode for better writing style · Issue #2000 · PowerShell/PowerShell · GitHub。

補充 3：如果這裡涉及商標侵權問題，我支持徹底幹掉這兩個別名。

這個別名我忘了是4.0還是5.0跟著Invoke-WebRequest引入的。我也中過招，不過在windows可以加.exe後綴來調用原生的curl, 其他平台沒有後綴啊，難道得用絕對路徑？求指教。

要微軟砍掉就太過了，一來破壞了原來powershell腳本的兼容性，二來微軟起了相當多類似的別名，如ls, rm, mv，這些都不兼容，難道都砍。

我覺得還是高手提供一份powershell profile腳本，教別人把看不慣的別名給禁了

這事情的關鍵是，curl的作者要求MS為了適應一個既不是Windows自帶，也不是Windows原生的「業界知名工具」，去修改一個從09年至今存在了7年的，並且刻意在Linux版上面不生效的別名。

換句話說就是軟體作者要求一個操作系統的組件主動去兼容自身……

怎麼看都不是你說的「實際上用的就是curl」吧，微軟自己開發了一個Invoke-WebRequest的命令，然後自作主張給命令起了個別名叫curl。PowerShell的設計是跟批處理一樣可以調外部可執行程序的，本來使用curl調用的應該是外部的curl.exe，這麼一弄不管是curl還是wget調用的都是PowerShell的內置命令了，但是兩個命令行根本就不兼容，而且作為一個知名軟體的作者，當然不會希望Windows的某種Shell裡面用自己軟體的名字的命令，調用的是不是自己軟體的東西，這根本就是一種挑釁。要求刪除實在合情合理。

真是蛋疼，還不如好好陪陪女朋友。

curl在Linux下面的PS反正用不了。

知名軟體被另外一個軟體冒名頂替…

這麼說吧，如果哪天微軟突然把自家的win10 mobile改名叫ios了，蘋果來告微軟侵權，你覺得蘋果是過來丟人嘛？

貌似iwr是後引入的, curl別名是跟iwr一起引入的, 也就是說, 在iwr和curl別名引入之前, 我的腳本如果直接調用path裡面的curl, 升級到新的PS之後會不能正常運行 (參數用法都不同).

那麼當初引入這個別名的時候可以break現有腳本, 為啥現在不能break了...

我個人是支持刪掉這兩個 alias 的。

（更新：我詳細讀了一下 issue #929 這比那個 pr 下面干正事多了。。。我現在支持的是把 alias 提出來，然後可以用 command enable，比如 enable-alias dos 和 enable-alias unix 來 enable 這些 alias，如果 profile 裡面沒有的話，默認不開，只用 iwr 和 gci 之類的 PowerShell alias

這樣既表達了 script 裡面盡量不要用 alias，也方便了喜歡 unix 原生的用原生的 tool，對想要用這些 alias 的 PowerShell 用戶，開啟這些 alias 也很方便）

=========================

這是 Windows 和 Linux 設計的問題。Windows 原本沒有 curl 和 wget。為了方便，微軟把原來的 invoke-webrequest alias 成了 curl 和 wget。

這在 Windows 平台上沒什麼，因為你可以 curl.exe

但是 Linux 上沒有 exe 啊。。。而且更致命的是原作者說的 working no where near the original curl。。。這樣造成了大家在 linux 的 PowerShell 下面無法調用 curl 的窘境，而且逼迫大家用著一個和 curl 語法完全不同的 curl。。。這對誰來說都是很彆扭的。

至於為啥 ls 不會被噴。。。因為 ls 至少還差不多，你 ls 一下都能達到看看文件夾裡面有什麼這個目的。。。但是你用 curl 然後就必須要在後面獲取 content 才能得到網頁內容，wget 必須要寫 out-file 才能下載，這是讓剛來 PowerShell 的人很苦惱的事情。。。

我覺得你既然已經決定跨平台了，就要有跨平台的姿態嘛。。。

如果有人真的覺得更喜歡 PowerShell 的 curl 或者 wget，那麼可以自己弄 alias 嘛。。。而且這不是有 iwr alias 么，還可以少打一個字呢。。。

至於刪掉了之後之前的 script 會出問題。。。額。。。反正在 script 裡面用 alias 就是不好的習慣。。。而且還是趁著現在沒啥人用 PowerShell 趕緊刪了吧。。。萬一以後用的人多了，這就很難搞了。。。

或者寫一個 disable-alias cmdlet 也好。。。

（更新，仔細讀了一下，你可以用 remove-item alias:wget 來刪除 alias）

=========================

接著更新。。。大家可以看看那個 issue 下面的 *nixer 的反應。。。簡直就是小劇場。。。

我雖然支持處理這個，但是底下的一般人的反應真是不能苟同。。。

而且 PowerShell 之父都已經發話了，要處理這個問題了。。。

這底下一般 *nixer 還是咬文嚼字不依不饒的很可以。。。

最後 ps 他爸爸跟他們說了一個 fine，就沒說話了哈哈哈哈哈哈

提個win平台下alias會出現的問題。

用chrome抓包可以直接copy as curl（cmd）或者copy as curl（bash）

無論是在PowerShell下面還是cmd下面都是無法運行的。

怎麼看？當然是在電腦屏幕上看……

-----------------正經的分割線--------------

PowerShell 是從Windows 上發展起來的，Windows 上一般沒有 curl, 因此弄了個 alias 。後來開源了，跨平台了，和 linux 里的 curl 名字衝突，於是作者過來把這個 alias 刪了。

但是！這個改動會導致原來 Windows 上正常工作的腳本出現意外，所以直接刪除是很不嚴謹的，並且有害。更糟的是原來的 alias 和 curl 介面不兼容，不能簡單的通過安裝 curl 解決問題，因此才是個更麻煩的技術問題。

這是歷史遺留導致的磨合問題，別總扯到陰謀論上吧。如何優雅的解決問題才是我們需要考慮的。

一般大家寫工業級別的 PowerShell 腳本都不會用 alias 來寫吧，一個函數有好幾個別名，這是真的很蛋疼。

這樣啊，請問我們這些使用Unxutils的人要怎麼說……

這要是換成Oracle，直接告微軟侵犯了他的姓名權，哦不，商標權

看完了整個撕逼現場……最終感覺還是curl作者的建議最make sense，甚至對微軟也是如此。

各位軟道士不妨暫停下舉起的狼牙棒，想想微軟開源powershell是為了什麼？

無外乎為了擴張powershell的社區，擴張.net的影響力嘛。萬一火了還能有開源社區給添磚加瓦。

那麼按照你們的想法，不在windows版上移除這個alias，除了可以讓那些連自家人都不願維護的腳本不被break，給蜜汁道路自信添點柴火，最顯然的後果就是windows powershell和posix powershell用法將截然分開，兩邊腳本無法互通，成為事實上的獨立流派。不存在兼容可能的流派很難不發展為徹底分裂。而一旦社區分裂，posix powershell作為無本之木註定式微，讓微軟一番心血空投。這就是你們願意看到的？

與其這麼下去，為什麼不看到powershell當初加這些alias本來就是一個不得已的選擇呢？不想帶GPL binary被GPL傳染，你就直說嘛。反正現在又不是沒有WSL，還有ubuntu投獻的到現在也沒給FSF找出協議茬來的binary。擔心兼容性問題的話直接做版本卡斷就完了。至於現在WSL binary只有bash.exe入口這個問題——微軟這種既不微也不軟的體量，不就是用來集中力量干大事的嘛。

根本就是用一個會帶來兼容性問題的方案來cancel掉另一個會帶來兼容性問題的方案，拿底層碼農當猴兒耍

讓我站隊的話：現在怎麼樣就怎麼樣，別再改了

類似我討厭復古繁體字，不是覺得簡體字好，只是因為嫌麻煩，不折騰

如果當時沒發明簡體字，我也會討厭現在簡化漢字的