為什麼總有人極力推薦使用命令行操作而非圖形界面？
因為其實我們推薦的不是圖形界面也不是命令行界面，而是「自動化」。
因為命令行本質上是邏輯的文本化描述。
同樣是文本化描述邏輯的還有代碼。這也解釋了為什麼程序員更喜歡命令行。因為一旦邏輯文本化，那麼就可以對邏輯進行抽象，保存，優化，很多人不知道命令是可以保存的，windows 上的bat 腳本見過沒？那用記事本打開就是一堆文字而已
別小看這個抽象能力，邏輯是有層次的，當把低層次的邏輯封裝起來，就能在更抽象的層次上高效的表達邏輯。而滑鼠是難以做到的。
如果邏輯能夠保存，就能夠獲得持久化和分享的能力，以及持續改進的能力，當我們要求計算機執行複雜任務時，往往我們沒有辦法思考的很全面，這時，如果他人的經驗能直接以可執行的文本傳播，將節省所有人的時間成本。
通過抽象成不同的層次和持久化，命令行永遠能夠以一種簡單的調用完成滑鼠操作遠遠完不成的任務
為什麼程序員都該學點命令行?擼了個小視頻演示下（mac下 iterm2 + oh-my-zsh(spaceship主題) + tmux + neovim，代碼沒啥意義，只為了說明問題）對開發者來說，有以下一些優勢吧（算不上極力推薦，但GUI/TUI 各有使用場景）:
PegasusWang：完全不用滑鼠寫代碼！你信么？[視頻]?zhuanlan.zhihu.com![圖標]()
自動化
終端下的一大優勢就是你可以用 shell/python 等腳本來完成很多自動化工作，比如進程自動重啟，定時任務等。 比如我有這樣一個需求，每次修改代碼的時候重新跑單測。我們可以用一個文件監控工具監控文件變動之後自動執行測試命令。
pip install when-changed
然後我們把一下代碼保存到一個 test.sh 的文件里，加上可執行許可權 chmod +x test.sh
#!/usr/bin/env bash# pip install when-changed, 監控文件變動並且文件修改之後自動執行 pytest 單測，方便我們邊修改邊跑測試
when-changed -v -r -1 -s ./ "py.test -s $1"
./test.sh somefile.py每次我們改動了代碼，就會自動執行代碼里的單元測試了。pytest 會自動發現以 test 開頭的函數並執行測試代碼。良好的工程需要我們用單測來保證，將來即使修改了內部實現邏輯也方便做回歸驗證。
再舉個例子，我經常使用谷歌瀏覽器的 copy as curl 命令來把一個請求複製成 curl 命令，然後我想把它轉成 requests 請求, mac 終端下可以這麼搞，假設你已經拷貝好了：
# pip install uncurl
pbpaste | uncurl你就會看到代碼轉成 python requests 代碼輸出啦。然後你可以修改各種參數來進行調試。
終端下 find, htop, curl/uncurl, pyenv, nvm, git, tmux 等一大堆可以提升工作效率的命令行工具。只要你會使用 shell/python 等腳本語言，就可以按照自己的需求編寫一些工具腳本來用。
高度定製
只要你會一些簡單的 shell/python 等腳本語言，就可以根據需求編寫自己的命令行工具，從而幫助你解決一些重複性工作。（同時也是一種代碼練習，使用自己造的一些小工具比較有成就感）
方便地安裝軟體
如果你用過 mac 下的 brew 你會發現安裝一些服務端軟體非常方便。直接 brew install 就可以。
alias 簡化操作
比如我想下個 youbute 視頻，直接 pip install youtube-dl，
然後在我的 ~/.zshrc 加上這麼一句:
alias download_youbute_mp3=youtube-dl --extract-audio --audio-format mp3
alias download_youbute=youtube-dl -f bestvideo+bestaudio然後 source ~/.zshrc
想下載油管視頻和音樂不用太方便，直接上邊命令加上 油管地址就好了。
直接python 腳本批量並發下載視頻不要太爽。
download_youbute_mp3 https://www.youtube.com/watch?v=2zda1Tr4big全鍵盤操作
我平常使用終端 neovim 編寫 Python 代碼，使用 Iterm2 + Oh-my-zsh + neovim + Tmux 全程純鍵盤操作，打字過程不會打斷。 對筆者來說還是挺喜歡這種感覺的，可以葛優躺捧著鍵盤完成所有編輯操作，還可以用 Poker2/HHKB 之類的迷你鍵盤，把手指集中在主鍵盤區就能高效操作。（我個人不喜歡敲代碼的時候還得來回碰滑鼠或者觸摸板，影響碼字體驗）
批量、重定向、管道操作
比如我想刪除一堆文件直接 cd 到一個目錄然後執行 rm *.mp4，使用文件管理器你需要手動選擇很多文件操作。 unix 哲學之一就是 "do one thing, and do it well"，但是 unix 很多工具都可以通過管道組合使用。 我想刪除一個項目下的所有 pyc 文件，可以直接這麼用:
find . -name *.pyc -delete
比如我想找出所有包含 python 單詞的文件並且把結果重定向到一個文件(ag 是一個需要單獨安裝的搜索命令)
ag python &> python.txt
通過管道把一個命令的輸出作為另一個的輸入，我們可以統計當前 ls 的結果有多少行：
ls | wc -l
伺服器操作
某些場景下比如登錄到 linux 伺服器只有命令行可用，後端和運維工程師經常和伺服器打交道，熟悉命令行會大大提升工作效率。 比如 tmux 終端復用工具就非常方便地去管理終端會話。
對於普通用戶來說，我覺得倒是沒有太大必要使用命令行。但是對於後端/運維工程師來說基本就是必備技能，筆者當初找工作(web後端)經常被問到各種 Linux 命令，大部分互聯網企業用的是 linux server 部署 web 服務(微服務容器部署等)。
更原始也更底層
現代 IDE 開發工具很強大也很方便，但是有時候會隱藏太多底層細節。直到我學習了linux 下 gcc/vim/make 等工具之後，才對代碼如何從文本到二進位文件有了更深刻的認識。如果你不熟悉 linux/unix，我想你看《c 程序設計語言》《計算機程序的構造與解釋》這種書會比較吃力，裡邊使用到了很多命令行工具，很多教材都是基於 linux 環境講解的。
以上只是筆者日常使用到的一些經驗，每種工具都有自己的優勢和使用場景。大家有啥小技巧可以留言交流。
![]()
玩轉 vim 與 Terminal (視頻)?zhuanlan.zhihu.com
排除一些只能使用命令行的情況，其實命令行在某些場景下仍然有不可替代的作用。我接下來說的可能也是 Linux 下的用戶很多時候明明在有 GUI 的情況下而仍然通過 CLI 管理系統的原因。
在 Linux 上有很多程序是前後端分離的設計，例如 aria2 和 wget 可以被 GUI 程序 uGet 當作後端，而且 aria2 的分離式設計更加通用，自身提供基於 web socket 的 RPC 介面，所以連網頁就能成為 aria2 的前端。例如在線版的 Aria2 Web 控制台 或可以自己部署的開源前端：ziahamza/webui-aria2。
類似的太多太多了。我們可以使用 GUI 更新系統、安裝軟體、管理用戶，現在的桌面配套組件和第三方前端軟體非常豐富，幾乎可以讓大部分的事情都通過 GUI 來做。
但是，我卻連最基本的安裝軟體和更新系統都會打開終端輸入命令，你們猜為什麼？因為 GUI 前端的宗旨普遍就是面向普通用戶設計的，例如後端出錯了，前端很多時候不會告訴你錯誤原因，只告訴你出錯了。你除了重來一遍幾乎別無他法，因為 GUI 軟體普遍能提供給你的信息太少太少了。
雖然，我僅僅只是更新個系統，在 GUI 上點一下檢查更新然後在彈窗中點下載安裝就行了，又或者打開終端輸入一條重複過無數次的命令，看上去異常的簡單。
但其實，即便是如此簡單的操作，可能導致出錯的原因卻連數都數不清，只有你想不到的。例如我曾經因為某科學上網環境配置錯誤，導致 DNS 出問題，這個問題僅僅會導致 wget 無法解析域名，瀏覽器是正常的。因為 wget 無法解析域名又會導致其它組件下載不了內容，最終導致更新失敗。
在 GUI 更新工具的前端上除了告訴我下載失敗以外什麼都沒有，我萬萬沒想到是 DNS 導致的這一系列問題。但是如果使用 CLI 更新系統那就不同了，因為你默認就好像進入了一個 debug 模式似的，可以看到非常詳細的輸出內容，如果有問題往往進程就直接 panic 掉，錯誤消息甚至 backtrace 都被列印得一清二楚，所以你的第一反應就是知道了導致問題的最根本的原因。
這並不是什麼 CLI 或者 GUI 哪個效率更高的問題，這是考慮效率之外的另一個會選擇命令行的因素。
再說我前不久遇到的第二個例子。我通常都是使用從 Github 下載的二進位文件啟動 Telegram 來使用的，但是缺點是不包含在包管理體系以內。於是有一天我從 snap 商店中安裝了 Telegram，但是奇怪的是我啟動 Telegram 要接近 10 秒鐘的時間，而且字體有異常。但是 Telegram 的窗口並不會告訴你任何事。
於是，當我用命令行啟動 Telegram 以後發現一堆有關 fontconfig 錯誤的輸出，顯而易見這就是原因，當我把它們解決掉就一切正常了。如果我不通過 CLI 啟動，那麼除了不斷嘗試毫無作用的卸載重裝以外什麼也幹不了。
同樣的，在 Windows 上也有這個現象，我並不會對第三方軟體舉例，就說 Windows 自身的功能。有一段時間，我無法在 Win10 商店上下載任何東西，只要點了下載按鈕整個商店程序窗口就會閃一下然後自動重新載入當前的應用頁面，無論怎麼試都無用。
雖然 Windows 不會給你錯誤的詳情，但是通常會給你一個錯誤碼，你按照錯誤碼來搜索一般也能找到出錯的原因。但是我那個莫名其妙的經歷奇怪就在 Windows 連個錯誤碼都不給我，我點下載它就自動刷新一遍。後來還是我自己發現了規律，原來是我開某不和諧軟體導致的，它可能對商店的網路介面產生了影響。假設我能通過命令行啟動商店或者安裝應用，那麼我就能在第一時間看到錯誤的根本原因，比什麼錯誤碼更加直接得多。
如果讓我舉個例子，那麼命令行就是一種自帶 debug 模式的軟體使用方式，能讓用戶看到更多的更根本的東西，更加的「面向開發人員」。
因為對專業人員來說，命令行的確比圖形界面強大，方便——就好像專業人員喜歡使用術語而不是拿大白話展開讓每個人都「懂」一樣。
當然，強行「拽」術語甚至誤用錯用術語搞後現代文本風，那就是另一回事了：這種行為值得鄙視；但必須注意，該鄙視的是拿術語裝X的行為；甚至，和普通人說話時，該說人話他們不說人話你也可以鄙視；但對於想成為內行、需要和同行高效交流的人，提倡術語才是明智之舉。
滑鼠是一種更偏模擬量的輸入設備，它在輸入模糊性的「大概這裡」「大概那裡」之類信息時非常高效——因為人的思維本身就有一定的模糊性，轉換成語言文字甚至具體的縱橫坐標等精確指令，反而帶來很大的思維負擔。
因此，在畫圖/修圖等軟體里，滑鼠往往比鍵盤更好用。因為我們真正需要修的可能是畫面中模特的「鼻翼兩側」，用鍵盤就要轉換成明確的（81，97）開始的一塊不規則區域——可以做到，但為什麼不可以是（82，101）呢？
甚至，我該怎麼知道模特鼻翼左上角坐標是（81，97）都是個難以解決的問題。這時，不需要動腦子直接可以指上去的滑鼠，顯然要優越得多。
以上，就是「只能用大白話拽術語純屬裝X」的場景。
計算機本質上是個數學機器。精準的使用術語是一個門檻較高的工作。
此時，就好像輸入法的聯想功能一樣，設計一個「上下文菜單」，幫用戶選擇合適的命令，自然就能大幅提高他們的輸入效率、降低記憶負擔。
這種情況下，圖形界面也是優於命令行的。
但，只要稍進一步，情況就悄悄發生了變化……
和輸入法的聯想功能一樣，如果你需要輸入的東西稍微生僻、它就是「聯想」不起來呢？
做計算機命令方面的聯想，比輸入法還要難得多。畢竟後者有海量語料庫（但作為專業輸入者，你還是需要掌握生僻字的輸入方法，不能依賴聯想）。但在某個界面上（比如AutoCAD），可行的上下文甚至可能有無限多種。
除非在某個極為狹隘的領域做一些單調重複的簡單工作，否則，只依靠程序員拍腦袋給你拍出來的「上下文菜單」，是不可能順暢完成日常工作的。
你需要做的工作越複雜，「智能聯想」能提供的幫助就越少。
同時，為了提高「智能聯想」的命中率，我們寫程序時，往往不得不盡量減少用戶的可調參數——比如，為了照顧普通用戶，我們不敢說去除噪點（參數xx半徑yy強度zz）、色彩增強（RGBα顏色通道上的各種操作以及另外一大堆參數）等等等等，而是把所有這些放到一起、搞出十幾個固定風格讓用戶選，還告訴用戶說這種高科技叫「一鍵美顏」，結果輸出五毛錢特效……你要開照相館靠這個能應付挑剔的專業顧客？
此時，智能聯想不光無法提供幫助，反而成了專業用戶的阻礙——想想如果要你用美圖秀秀做商業海報，你會不會罵娘呢？你會不會想念PS那嚇死普通人的專業菜單？
顯然，一旦面對的問題複雜到一定程度——既然你已經是數學家/科學家/計算機專家了，為什麼不直接用精確無歧義的術語呢？
把術語都日常化，的確便於科普；但到了學術交流階段，不說「扭矩是xx牛頓·米」而說「大概像你手掌上放xx本書時手肘受到的力」，不僅是浪費與會專家的時間，實際上也不可能說清楚你真正想表達的「效率-扭矩曲線」這種高端玩意兒了。
計算機領域也一樣。
以上是受 @pansz 朋友的啟發，這才能夠說的一步到位。
pansz：為什麼總有人極力推薦使用命令行操作而非圖形界面？
以下是原帖內容。因為當時沒整理好思路，因此說的比較凌亂。不看也罷。
舉例來說，我有個硬碟壞了，讀取速率經常掉到2m以下，還頻頻出錯。裡面有500個G的資料要搶救。拷完得差不多一兩天，還得人坐旁邊看著，錯了停了就重拷，再拷貝時要跳過重複文件（現在還好，win10有跳過文件功能），不然很可能拷到同樣位置又出錯了。
如果你用圖形界面，那麼你就需要找一個精確吻合你需要的軟體，然後一點……點這下當然很容易，可找軟體能累死你，因為這種需求太小眾了。小眾軟體太難找甚至壓根沒有，就是找到也經常要掏錢買，不過相比搜索難度就不算什麼了。
但如果你命令行玩的很熟練，那麼很容易就可以組合幾個常用命令，輕鬆完成任務――甚至還可以帶斷點續傳功能、拷完可自動關機。
換句話說，命令行模式的確需要你記憶更多命令、孰知一些通用約定；但這些東西可以作為基礎，搭建出任意複雜的功能來。
當然了，這也導致它的入門門檻略高，對非專業用戶來說得不償失；即便專業用戶，當針對該領域的軟體已經較為完善時，不去用現成的圖形界面工具就是捨近求遠了。
甚至，組合這類命令本身，往往就要求你有一定的編程基礎，對非程序員來說那是加倍的不合算。
當然，如果你已經是程序員，那麼學會使用命令行（腳本），起碼可以在遇到類似問題時，解放你一兩天的時間。
剛才手機答的，現在稍微展開點說一下。
這裡有一個圖形編程工具，是MIT為兒童學習編程設計的：Scratch - Imagine, Program, Share
你猜為什麼它就是比不過python、java、C++呢？
各行各業，做事都免不了要用工具；但工具和工具並不一樣。
舉例來說吧，你在家做飯，完全可以用這個：
![]()
但如果你要開個店賣麵條，還用上面那個說明你傻。這玩意兒才值得擁有：
圖片來自網路，侵刪 但如果你說我要造麵條機……那麼你該買的是這個：
很容易發現，越是面向最終消費者的工具，功能就越是單一，操作也越是簡便——量面，倒水，一鍵出麵條。弄傷自己？嗯……舉起來砸自己腦袋算嗎?
越是面向專業人員的工具，功能就越是複雜，操作界面也多了很多按鈕/儀錶；如果不注意操作規程，就容易不小心弄傷自己。
但是，在付出這些代價的同時，你也得到了極高的生產力、可以做的麵條厚薄、寬度的可調範圍也大幅增加。
最後，給專業人員製造工具的工具，其複雜度更為「恐怖」，工傷成了家常便飯：
【活著】工傷檔案_騰訊新聞_騰訊網
東莞每年因沖床工傷著達數萬人 - 上海二鍛沖床有限公司
我們再換一個角度。
麵條機雖然最終功能單一，但它有機的組合了許多功能，從攪拌和面到麵條擠出，一條龍服務……
等等，你說，它也有電機啊，拿來擰個螺絲行不行？
不好意思。它可擰不了螺絲。擰螺絲你得找這個：
你說，還不對啊，這玩意兒能擰任何螺絲、也可以配合各種型號的鑽頭……麵條機能做粉條嗎？不都是條狀可以吃的東西嘛？
你看，刀鋸斧刨錘，這幾樣湊一塊足夠做任何木工活了。麵條機……
沒錯，這裡還有一個維度：工具的泛用性。
這玩意兒好用不：
好用？我這有個旋翼機，你用它能做飛控嗎？
顯然不行。做飛控你得找它（以及其它類似的東西）：
沒錯，沒那個現成的計算器好用，前者開箱即用，算賬全靠它；後者……對不懂計算機的你來說，它和一塊磚頭沒多大區別——還不如磚頭好用呢，起碼墊腳啦拍人啦拿來就用。這樹莓派啊，吃不能吃喝不能喝梳頭髮都別彆扭扭不好用……
但是樹莓派有無限可能。
對工具使用者來說，他總是有兩個選擇方向：方向一是只能做一樣的專用工具，方向二則是泛用型的基本工具。
專用工具單件學習成本低，使用方便；泛用工具學習成本高，使用不便，甚至常常伴隨著危險。
作為生產廠家，你可能會買椅子生產線；但作為一個高級木匠，你肯定選擇帶鋸機、木工機床。因為只有後者才允許你發揮自己全部的專業才能——生產線？我造生產線。
作為木匠，藉助木工機床，他是萬能的；買條生產線他就只能像沒有技術的農民工一樣接收半月培訓坐生產線旁邊當螺絲釘，然後只造同一個型號的椅子（的一個零件的一個面、一個孔）。
換句話說，對專業玩家，學習使用更接近根本、泛用型更強的工具，效率反而是更高的。
就好像我們程序員，說白了只會順序分支循環三種控制結構和與或非三種邏輯——然後藉助某種編程語言幾十個關鍵字/運算符表達出來——經過四年學習，便可宣布計算機領域我全能。
反之，你要只會玩war3地圖編輯器，這個圖形界面可強大了——給你八年時間，你能用它清理磁碟嗎？
欲速則不達。
單件學習效率高的工具，在面對一整個大領域的問題時，往往反而是更難學難用的。
因為做100種傢具你就不得不學習使用一百條生產線，每條生產線又有100個位置……你得掌握一萬個知識點才可能做出100種不同傢具。
再多一種傢具？從頭學吧。
但如果你學鋸刨鑽斧，學木工機床，只需掌握至多幾十個知識點，你就是萬能的。
沒錯。這裡就是圖形界面和字元界面設計著重點上的根本不同了。
圖形界面就像計算器，你需要什麼功能，它就給你什麼功能；無論供電、顯示甚至長時間不用自動關機節約電量等等，都用不著你操心。
Do not make me think——這是圖形界面設計者對它的用戶特徵的總結。
當然，一旦認為用戶需要「Do not make me think」，那麼結果必然要走向「禁止用戶思考」——除了按鈕，你什麼都不要知道。讓你知道了就說明我「封裝」沒做好，又勞駕您動腦子了。
久而久之，哪怕你清清楚楚知道後台的一切，你也沒辦法控制它了——就好像win10飽受詬病的強制更新等機制一樣：我筆記本網卡很奇葩，win10驅動下它就是上不了網，只有win7驅動可用；但為了使用win7驅動，我不得不和它那噁心人的「傻瓜機制」鬥智斗勇一整天！因為從調查排錯到替換驅動，它時時處處拿我這專業人員當傻逼，時時處處給我製造麻煩。最後，強制關閉完整性檢查、建立win10版驅動同名目錄並給這個目錄設置極高訪問權，這才阻止了win10做蠢事，使得它不再強制把正常的win7換成錯誤的win10驅動。
如果你確信自己不需要了解背後的原理，確信自己永不必處理軟體作者沒有想到的奇葩狀況，那麼傻瓜式的圖形界面顯然最為適合你。
而字元界面類似樹莓派。它不僅給你現成的功能，還給你完成任何功能所必需的基礎——你可以把任何現成的功能當成基礎組件，用來搭建更酷更炫的東西。
最最極端的例子就是圖靈機，或者各種編程語言——沒錯，這些玩意兒功能簡單，簡單到了醜陋的地步。以至於仨數字排個序都需要自己寫程序才能搞定。
事實上，最最「簡單」的機器語言，你得自己做二進位轉換；彙編語言可以幫你把「助記符」轉換到二進位；C/Java等高級語言可以讓你用if/for/class等更為高級的概念直接編程；而更「高級」的腳本語言……你只需像膠水一樣把它提供的半成品往一塊一粘就好——要什麼你就能「粘」出什麼。
而命令行的設計思想，就是「搞一種比腳本更高、但比計算器更低的東西」——不，它實際上是把計算器本身都當成一種組件、一個工具，從而允許你自由組合它們。
比如，我可以這樣：
call 自動打蛋器 //打出雞蛋液
call 自動麵條機 //加入雞蛋液做成雞蛋面
call 電磁爐 //煮麵
call iPhone //喊你家的小懶蟲起來吃飯
添加細節，調試通過，存成「一鍵做雞蛋面.sh」，然後在桌面建立個快捷方式——該吃飯了滑鼠一點，一會兒電話打過來你就可以去吃麵條了。
如何？酷吧？
N年前，我有張光碟劃傷了，數據怎麼都讀不出來。有個文件時多時少，總是讀若干位元組就出錯。用了當時流行的很多數據恢復軟體都讀不出來。
但這個故障我很清楚，就是表面稍微擦傷，導致數據難以讀出。每次根據激光聚焦點位置的不同，能夠讀取的數據也各有不同：近一些能讀前4k，遠一些能讀後4k；偏左點能多讀接下來的4k，再偏右點又能把尾部4k讀出來……總之只要多試，利用激光頭的隨機誤差，就有一定概率能救出全部數據。可是很遺憾，我找遍了當時各種數據恢復軟體，包括很多商業數據恢復工具的破解版，全都無能為力。後來我都打算自己寫程序fseek一把了，忽然想起個主意。於是把光碟路徑設定為ftp服務目錄，然後用斷點續傳工具從這個自建ftp站點下載，重試次數無限——這樣實際發生的物理行為就是我所期望的場景——果然，僅僅消耗了4、5分鐘，就把完整內容讀出來了。當然了，這個其實是用圖形界面軟體做的。但是這裡面有個思想很可貴，就是工具是可以組合起來用的，並不需要別人全給你做出來。有一些基礎功能，然後再允許你組合，那麼絕大多數任務你自己就可以通過組合搞定。命令行鼓勵你組合使用各種軟體——當年的DOS甚至把它們統稱「外部命令」——從而得到無限的功能。只不過，window的命令行是個閹割品，你實際上很難很難藉助它粘合各種軟體。這樣也好。各種各樣的標榜自己可以「數據恢復」的劣質品就可以上架賣了（當然，專業的數據恢復軟體還是很強的，只是它可能恰好沒有我想要的功能而已）。再來個例子。
我的筆記本自帶硬碟只有320G。對我這種重度使用者來說顯然不夠。後來又買個1T的希捷deskjet移動硬碟作為補充。但沒多久，50G容量的C盤已經滿了（當時大部分人分給C盤的容量只有10G左右，很少捨得給20G的，我直接給50G）。實在忍受不了，買個新硬碟打算升級。但這個筆記本上有我已經配置好的全套環境，原有的windows還是正版。重新安裝實在勞民傷財。很多高人馬上就會想到ghost：把C盤用ghost做個影像，然後把影像寫到新硬碟第一個分區；寫完用PQ Magic擴大這個分區；然後再在新硬碟上分出D、E區，繼續用ghost把舊硬碟其它分區做成映像複製過來——同時按需要用PQ magic擴大分區。簡單說，你得下載（很可能是盜版的）ghost和PQ Magic（其實PQ magic當時已經不支持win7的ntfs分區擴容了，所以你得滿世界找替代的、可支持ntfs的軟體）；然後等著ghost一個個做映像；然後一個個寫入映像、修改分區大小……總之，起碼5、6個小時離不開電腦。我的做法是，找個U盤，在上面做Linux live CD。把新老硬碟同時安裝到電腦上（當時就打算用老硬碟做移動硬碟的，所以同時買了移動硬碟盒）；使用U盤啟動，打開Linux終端，su切換到超級用戶（root）。使用fdisk為新硬碟分區，其中C盤分200G，D、E等分區同樣放大；另外又給linux分了幾個區，打算做雙啟動。然後執行如下命令：dd if=/dev/sda0 of=/dev/sdb0 bs=16Mdd是Linux下一個強大的數據複製工具；Linux下一切皆文件，因此sata介面上的磁碟a的第0個分區同樣可看作一個普通文件，磁碟b情況類似；if=/dev/sda0意思就是以老硬碟最前面的分區為輸入；of=/dev/sdb0意思就是以新硬碟最前面的分區為輸出；bs=16M意思是一次拷貝16M的數據，這個不同的系統有各自最合適的值，你可以多試幾次，看看選用哪個值拷貝速度最快。因為這個命令是把整個分區當文件順序讀寫，因此無需頻繁尋道，數據複製速度可以一直壓著硬碟理論最大值飆車。dd (Unix) - Wikipedia還有N個區？很簡單，繼續往下寫dd if=/dev/sda1 of=/dev/sdb1 bs=16M就好了。然後，繼續敲resize2fs /dev/sdb0，它會自動把該分區的文件系統大小調整到和分區實際大小相符。其它分區依此類推。敲完，存為cpsys.sh，chmod +x，然後多檢查幾遍，確認沒問題，執行./cpsys.sh &> cpsys.log接下來出去逛商場，逛到中午回來，cat cpsys.log | grep Error確認沒發生任何錯誤，關機，拔U盤，拔移動硬碟，啟動，一切就和原來一模一樣——除了磁碟空間變大之外。——對不會命令行的你來說，你得知道ghost、知道pqmagic，知道它們是幹嘛的、知道它們怎麼用（pqmagic不支持了你還得重新找重新學）；但對我來說，dd是個日常使用的、熟的不能再熟的普通工具，其它一切一切也都是老熟人。在整個過程中，我不需要學習任何額外知識，「吃老本」就足夠了。因為它們都是泛用型工具。一次投資，終身受益。說什麼IT行業千變萬化，說什麼IT一日千里，說什麼搞IT必須終身學習……但對掌握了泛用型基礎知識的人來說，所謂「日新月異」多半只是新瓶裝舊酒——比如說，我敢把ghost叫做「用圖形界面打包的、功能單一的dd命令劣化版」，而且的確可以隨手用三五行命令把它秒的渣都不剩。PQ Magic同理。你呢？什麼叫自由？你所掌握的知識都是你的，可以隨意的流淌於指尖，可以輕鬆愜意的達成你需要的任何目標，這才是自由。受制於商業軟體，人家不給你寫你就只能乖乖在電腦前坐5、6個小時；人家不支持了你好不容易死記硬背下來的一切就打了水漂——不會有人真有這麼大臉，敢把這個叫「自由」吧？當然了，我們都知道，麵條機是不可能這樣組合的。
很簡單，並沒有一個標準的、為了得到這種自動化而做出的輸入輸出約定。
因此，哪怕你集齊了打蛋器、麵條機、電磁爐、iPhone，你還是召喚不出神龍……哦不，服務不好你家的小懶蟲。
圖形界面有著同樣的窘境：你可以一鍵做麵條、一鍵煮麵；但你必須自己把麵粉+水倒入麵條機，然後自己把麵條放進電磁爐……
這就是我在評論區提到的：你可以勉強用按鍵精靈去組合圖形界面程序，但是你必須考慮界面卡死等等可能。浪費更多機器時間，功能還不穩定。
因為它們壓根就沒考慮過「程序之間的介面問題」。
而如果你玩的稍微深一些，就知道Windows下的rar、7z等壓縮軟體，都同時給你安裝了個非GUI版本，允許你在命令行通過參數使用它們——允許你把它組合進你的處理流程，這本身就是個極為重要的功能（事實上，很多GUI軟體都能接收命令行參數。越是偏工具性的軟體就越是不敢忽視這點）。
而命令行（特指bash等真正有管道、作業控制等支持的命令行，並不是Windows上那個李蓮英……哦不，cmd）從一開始，就考慮了這個協作問題。
學過C語言的，大概都知道main函數有一個返回值，這個值就是給命令行用的（其它編程語言都有類似支持）——0表示成功執行，非零是各種錯誤碼（不同的返回碼代表什麼也有統一的標準）。
*nix的shell不僅能捕獲這個返回值，它甚至還允許你捕獲、分析其它軟體在標準輸出/標準錯誤上的輸出內容，從而達到更深層次的配合。
尤其php、python之類腳本語言，它甚至允許你輕易的把「通過命令行調用其它程序」集成進你的代碼（其實C也很容易做到這些，它們甚至有專門的庫提供支持）——你完全不必操作字元串、也不必自己寫代碼完成http下載，丟給grep/wget即可：它們那麼強大，你再自己一點點敲一遍，不累嗎？
現在，當你買了麵條機，你就可以輕易把它們組合起來，從「一鍵做麵條」衍生出「一鍵做西紅柿打滷麵」、「一鍵做酸菜肉絲麵」等無窮無盡的功能。
換句話說，命令行犧牲了工具的易用性，提高了入門門檻，以保證其泛用性；而圖形界面通過犧牲泛用性，突出了其入門門檻低、易用程度高的優點。
當然，理想很豐滿，現實很骨感。
命令行的確給「腦子裡充滿奇思妙想又喜歡搗鼓」的人帶來了極大方便；但它本身卻因此顯得有些複雜了，入門門檻較高。這就使得它成了「專業人員」的玩物，缺乏計算機基礎的普通用戶只得敬而遠之。
很多時候，你必須先是一名程序員，才可能解放命令行的威能；但更多時候，哪怕你就是一名程序員——我只是想做碗麵條啊，為什麼一定要我先看完這一千多頁的鬼手冊？
人，總是喜歡偷懶的。
這時候，「點開即用」的圖形界面就顯得更強大、更方便了。
——我只需要把代碼編譯成APP，然後掛出去賣就行了；具體的編譯步驟、參數什麼的，隨便選一個不好嗎？
——什麼破光碟要組合這個組合那個，真有那需求我敲段C/Java代碼不就搞定了？
——更多更詭異的需求？買買買！都不掏錢買寫程序的不得餓死？
你看，也有道理，對吧。
你呢，你會如何選擇？
總之，不同人有不同的需求。單獨的一個個圖形界面程序足以解決80%以上的問題，而且還不斷有新的程序被寫出來，覆蓋更多的「痛點」。
也許，命令行所致力於解決的那額外20%的問題並不是你的需求；或者你可以忍受一定的不完美、或者你可以等更完美的成品上市。
不過，總有人，總有公司，總有一些業務場景，會遇到「不得不解決20%問題」的時候。
如果你善於組合，那麼很可能就能花一兩天時間（也可能更長或更短）解決問題；否則，或許你就不得不花十倍百倍的時間從頭寫出那些基礎功能、然後再組合出解決方案——再或者，你也可以提出需求，讓軟體公司給你定製軟體：這個世界上，絕大多數的軟體都是組合他人現成的庫/程序完成的，不怕多這一個。
這也是為什麼office為什麼要支持VBA以及微軟為何要從OLE到COM到COM+無限次推倒重來……從而把一些「可怕的細節」通過「可怕的編程語言」暴露給無助的非程序員們的根本原因——哪怕因此而導致宏病毒泛濫。
並且，現在Windows也搞power shell了。
沒有免費的午餐。
要麼犧牲易用性來保證泛用性，要麼犧牲泛用性來保證易用性——有些困難是本質上的。錢再多，你也不可能兩者兼顧。
如果你只需要解決「敲鍵盤時坐的舒服」的問題，那麼千萬別理什麼椅子生產線什麼製造生產線的工具，挑一把讓自己感覺最舒服的椅子就行了。
反之，如果你打算自己開家木器廠和別人競爭……你猜如果你這輩子都沒見過椅子是怎麼生產出來的，幾個「小目標」夠你賠？
但是，又一個轉折，你個做木器廠的，研究汽車發動機幹嘛？
當然，這裡討論的是「合理利用手頭一切資源」的問題。
也有人覺得敲命令便於裝B，另一些人則選擇懟這些裝X犯。這就是另一回事了。
因為所有的系統都有命令行，先有命令行後有圖形界面
而且很多程序員懶，你也沒給錢，懶得也沒空給你做什麼圖形界面
沒有圖形界面你就不會寫代碼了？
從資本家，不，企業家角度出發，雇一個員工，難道還要額外搞一個圖形界面？
這沒有成本嘛？開玩笑，哪有免費的午餐，雖然有盜版，但是盜版也是風險
被告了也是要賠錢的，這裡風險預算要留出來
所以對於不會命令行的開發人員，建議直接從工資里扣除50%作為圖形界面的費用
國外一個上過com 101的文科生都比這些偽開發頂用
不信隨便找個國外的com 101課程syllabus看看，看是不是都是從命令行開始
先說界面，不懂命令行的，不熟悉命令行普通用戶有多少，對圖形界面需求就有多大。
所以，我們可以只討論全球的普通用戶有多少了。
所以，你感覺到了有人「極力推薦」命令行，這又是另一個問題，這個取決於你的環境，你的職業，你打交道的人。站在一個更大的群體範圍內去看，我並不感覺到有人「極力推薦」，並且圖形化是趨勢。比如，你在一個全是程序員或運維人員的技術公司里部，他們大多數會說命令行好用，但是你在你們村裡問，他們會反問命令行是啥？讓我簡單直觀好用就行。所以你這個問題的問法讓我感覺是引戰，但是這個戰場很少人關注，應該不會成為熱門。
換個角度說命令行，圖形化不代表沒有命令行，命令行是底層，而要做一個好的圖形化操作界面，則是因為有更專業的人員將底層的命令行執行邏輯處理好了，同時也徹底消除普通用戶可能操作失敗，出現故障的機會，讓整個業務更完整流暢的運行，讓使用者專心去關注自己的特長業務，而不是什麼命令行。但是！轉折來了，界面做的好的軟體和應用不多了。。。好的都是公司產品級別的，要說個人軟體，基本上，太少了。原生GUI開發會的都不多了，JS類GUI開發倒是慢慢變多了，但是也只是給企業開發用的多。
任何事物都沒有絕對這樣，絕對哪樣，只有佔有比例的區別，按目前世界上的專業技術人中和普通用戶的比例來說，希望操作圖形化的人明顯是比命令行多的，其實在可預見的未來，專業技術人員是一定比普通用戶少的。所以在一定時間範圍內，存在就是合理，我們只關注要做什麼用途，就用什麼方式，這樣就都合理了，何必爭執。
PS1，另外說一下程序員，我們程序員喜歡用命令行嗎？也不全是吧，這個原因是因為，幾乎所有操作，需要命令行的操作，是完全沒有圖形界面！是沒有選擇餘地只能用命令行啊！ 比如：執行tomcat啟動關閉重啟及設置優化，如果有一個好用的圖形界面，我肯定不會用命令行！ 等等，這裡出現了一個「不好用」的圖形界面的反例，其實tomcat win下是有一個界面的，但是，這東西並不好用，長的丑也罷了，功能也弱，重要的優化配置功能根本沒有，有的功能也沒有必要圖形化，完全屬於可以忽略的東西。當然我可以另寫一個，總之還是我太懶。。。而且還要考慮更大範圍的周邊應用的使用，因為tomcat使用肯定是關聯一些其它工具。
還有一個反面教材的界面化，我記的是gradle，這個東西我記的某個版本是有圖形界面的，但是同樣，不好用，我想要的功能一個沒有，而且啟動運行非常緩慢，界面設計一看就是程序員設計的，沒有美感，沒有用戶體驗。。。在最近的幾個版本里，我已經找不到這個界面了。
PS2，想到一個事，外包中，甲方一些運維人員在接收項目時，有一些有界面要求，比如展示數據，管理等。另一些運維人員則不要，只要提供命令行。我們問，給你們提供一個界面產品可以操作唄，他們不要，只需要每次有項目更新，配置修改時，我們提供shell腳本。後來其它人告訴我們，如果你提供了界面操作，就必須保證界面操作的絕對！注意是絕對正確性，不能出現意外，不能出現錯誤無法解決的情況。如果使用了你的界面產品（如果我們提供了一個操作界面，這個界面就會做為一個產品功能，如果通過了甲方測試團隊，哪就認為我們的產品是合格的，我們只是交付，給出使用文檔就可以），出現了問題，哪就成了運維人員的責任了。但是，如果使用你提供的shell腳本，出錯了，嗯哼哼，這個責任就是你的了。。。到時候叫你來解決還是怎麼的，都是你的事。。
說的是程序員吧
程序員經常要重複做一些冷門操作（比如最簡單的批量改名然後再提取數據啥的），難道你要給每個操作寫一個 GUI？
這個問題已經長期存在並將繼續長期存在下去。在可預見的將來都不會消失。
GUI分兩種，好用的和不好用的。廢話，但標準因人而異吧，那我們換一種分類方法，高效的和低效的。還是廢話，但因人而異吧，那我們再換一種分法，滿足需求的和不滿足需求的。。。別打我，我不分了還不行
那我們來看一些可能屬於滿足需求且好用高效的GUI界面吧，超市收銀系統？銀行櫃員系統和火車票售票系統？銀行ATM系統和電視遙控系統？ 能滿足你的標準的系統是哪個？
說到底就是個滿足場景需求且訓練出習慣的問題。
好用高效的GUI都符合這麼些條件，適用範圍窄，僅封裝了少部分操作或者僅在部分操作上高效。
這就是螺絲起子和流水線機器人的差別而已，各有各的適用場景。實驗室里用螺絲刀組裝樣機而在工廠里用流水線生產成品。
我們可以投入更多的GUI設備來滿足特定的場景，我們還能發明語音手勢等拓展我們的GUI，但是凡事總有邊界，越過一定的邊界，看似笨拙的命令行反而效率高到天際。
就拿程序員和運維來講，有相當的工具支持一鍵發布，但是這個一鍵系統能一鍵處理異常故障么？不能。
那個滿足你的需求且高效你就用哪個，邊界處會變，會發生取代現象，但是總體上，這個邊界不可能消失，問題將永遠存在下去。
熟練之後CLI平均來說比GUI方便
絕大多數情況下CLI比GUI穩定一部分小眾工具只有CLI，因為開發CLI比開發GUI容易CLI更利於自動化運行，GUI則是直觀地人機交互不知道為什麼，有的時候CLI真的運行的比GUI快一點…CLI的輸入一眼就能看出來，並用程序模擬，GUI的話…反正我看不出來滑鼠坐標…CLI的輸出可以直接重定向到日誌文件…很多GUI沒提供這種功能…當然，最主要的原因是遠程伺服器帶不動GUI話說回來，即使最極端的命令行推崇者，也不會認為完全不需要圖形界面吧…
至少用CLI推gal感覺還是有點奇怪就是了…
- 效率。專業人員以效率優先，盲打速度大大高於滑鼠操作。
- 重複。一個複雜操作寫一次腳本可以多次復用。而GUI很難。
- 自動化。輸入輸出都是文本，便於自動處理。
- 傳輸速度。遠程操作中，處理文本傳輸所需的帶寬和傳輸的信息量均優於圖像。
如果有以上需求，命令行操作則優於圖形界面。正好這幾天我自己就遇到一個實例，做個註解。最近我的網站需要一個處理，要把裡面各種插件里所引用的 ajax.googleapi.com 地址替換成國內源。如果用GUI工具則非常繁瑣還容易出現疏漏。用命令行只要一行就解決了。我還計劃再寫個批處理每日自動運行，在插件更新後將需要替換的內容每日自動運行，自動處理替換內容。而本人基本不懂代碼，查查linux命令指南和google一下也就寫出來了。最終大大節約了自己的時間。
命令行玩的溜的人不會去鼓吹別人使用命令行，因為他們知道什麼時候該用什麼能最大提高效率
鼓吹的人多半是學會了一點命令行覺得自己很屌想要裝一下逼因為gui的生產性極差。
首先是可重複性。
gui幾乎無可重複性可言，比如你可以打開畫筆，看能不能用滑鼠畫兩條一模一樣的線？不能吧？
假設一項操作需要點100下滑鼠，你是沒法保證每次操作都點在相同的位置的。也許你覺得這不是大問題，因為每次點擊之前你都可以用眼睛修正，雖然不能保證完全相同的位置，卻可以保證每次都點在正確的按鈕上。
而每次點擊之前的眼睛修正就是巨大的人力成本。
你做一次倒是無所謂，做1000次呢？你有1000台伺服器是你自己一遍一遍做1000次還是找1000個人來做呢？
而命令行就要方便的多。因為它有極好的可重複性，同樣的命令輸入一千次一萬次也是一樣的結果。假設同樣100下滑鼠點擊的操作需要30條命令行的命令，那麼我只要在做第一次的輸入一遍，剩下的999次我就算是手動做也是複製粘貼一下就ok。這比你一下一下點效率要高多少？
你說我可以錄製宏啊。
可是宏同樣不靠譜。
就算宏可以完美的再現你點擊的位置和間隔（我們暫且忽略不同解析度帶來的影響），但點擊的時機也是無法再現的。比如電腦抽風卡了幾秒，該出對話框的地方沒來得及出，或者因為其他程序彈窗擋住了該點的地方，宏就直接點過去了，你猜後果是啥？
輕則操作失敗，重則重大事故。稍微嚴肅一點的環境是絕對不能這麼幹活的。
那宏要想靠譜一點呢？至少要在點擊前確認該點的地方已經出現在目標位置，最好點擊之後再能確認一下成功點上了。說實話這可是大工程，100次點擊每次都得這麼檢查一下，往少了說也得寫個300行的宏腳本才有戲。
可我明明30行命令就可以搞定。
接下來我們再說歸檔的能力。
對於大工程來說，詳盡的文檔必不可少。命令行可以非常容易的整理成文檔，比如出現xxx情況，則應輸入以下yyy命令。30行命令1，2頁也就搞定了。
你用gui要怎樣搞文檔？很多時候除了一頁一截屏還真沒有太好的辦法，100下點擊的操作你可能2，30頁也搞不定。
命令行的命令亦可以非常容易的整理成腳本。gui做腳本跟操作差太大，很難把操作直接轉化成腳本或者宏，如果需要腳本得單獨製作。這部分折算成人力也是大量的成本。
最後我們再說誤操作的問題。
前面已經說了，相對於命令行，gui的操作需要更多的人工參與。而人工操作越多則越容易引起誤操作。
一行命令乾的活你滑鼠點三下搞不定吧？那人家出問題的幾率就是你的三分之一，人家一條沒命令10幾個20幾個字元又不是現敲進去的，人家可以複製粘貼。
而且高度的可重複性就代表命令行可以事先在實驗室環境試好，落在紙面上由不同的人多重審核之後一個粘貼貼進去。你gui事前準備的再好也需要你一下一下按進去，更容易出問題。
而事後檢查人家命令行可以diff配置文件，gui只能把點過的地方一一打開，挨個看挨個查。
最後，出現問題了，回滾檢查，人家只要查終端的日誌就行了。輸的什麼命令，出的什麼結果一清二楚，你用gui操作還能每次都錄屏嗎？
綜合下來，gui出問題的幾率比命令行來說是差量級的，而且可能不止一個量級。
所以並不是鼓吹命令行，而是真幹活的時候命令行比gui好用很多。
命令行操作直接，對環境要求低。
這對於伺服器來說很方便。尤其是可以簡單的複製粘貼命令就能搞定很多事情。還有各種方便的特殊功能，比如管道，直接可以提高執行效率。更不用說還有腳本化帶來的便捷性了。
我不鼓吹用命令行。但有的時候不得不用命令行。
在Linux系統上，很多圖形界面實際上是在背後調用命令行工具，並且通過管道接收命令行執行的輸出，解析後再以圖形界面呈現給用戶。比如很多IDE的git插件/工具。命令行工具有很多參數和選項，組合起來有很多種用法，通常圖形界面只會實現其中一部分常用的，更高級的功能，比如要串聯好幾個命令行命令的操作，就只能手動輸入來執行了。
另外，這些圖形界面通常無法很好地處理所有可能的錯誤信息。不少工具只能顯示一個操作失敗，或者最後的錯誤信息。如果要診斷故障的原因，很有可能需要手動運行對應的命令來觀察中間的輸出。
我用了這麼多年命令行，現在傾向於認為，除去極端情況，大部分時候用命令行只是因為gui替代品的交互設計不行，或者人力不足以做出好的gui，沒有例外。
比如說我在小公司上班用的命令行工具，模糊搜索的時候fzf彈出搜索框，zsh命令補全的選項面板，以及tmux橫豎各種切分窗口，vim各種摺疊代碼和補全窗口，終究不是在命令行參數，而是在交互設計上下工夫，況且折騰半天也不過是一個poor mens gui，君不見Google微微一笑，掏出了自產的webide全家桶。
很多人舉例說「我需要遠程登錄xxx機器然後用終端編程」，本質上是因為linux的遠程桌面功能做的太差，開個x forward就卡成翔，遠不如rdp方便，所以只好刀耕火種而已。真正涉及到集群管理的時候，各種monitor panel還是用的web console，大家都是用瀏覽器點進去，圖表動畫一應俱全，放大縮小一目了然，哪有什麼命令行的事。
至於「用pipe組合各種命令行而不復用組件庫」本質上是一個糟糕的實踐，只是因為這麼多年來習慣成自然，改不了了，大家只好將錯就錯而已。各種bash自動化腳本配合sed awk鬼畫符毫無可維護性而言，歷史負擔越來越重，誰也不敢動，只好奉為圭臬，老人們再教導下一代的命令行使用者，這是一種循環。
- 圖形界面提供的都是一些大多數用戶需要的常用操作。對於一些特定的操作或者操作組合，圖形界面在效率上比命令行差太遠了。比如 Windows 更新總是失敗，嘗試刪除更新緩存。圖形界面要這麼操作：1) 右鍵【開始】按鈕→計算機管理→左側欄【服務】2) 在右側的服務列表找到【Windows Update】右擊它，選【停止】3) 打開資源管理器，進入 C:WindowsSoftwareDistribution 文件夾4) 按 Ctrl+A 選中所有文件，然後按 Shift+Delete，在彈出的對話框里選擇「是」，清除所有的緩存5) 右鍵【開始】按鈕→計算機管理→左側欄【服務】6) 在右側的服務列表找到【Windows Update】右擊它，選【啟動】而命令行的話，這麼操作：1) 右鍵【開始】按鈕→【命令提示符（管理員）】→UAC 點【是】2) net stop wuauserv3) cd C:WindowsSoftwareDistribution4) del /a /f /s /q *5) net start wuauserv
- 有些操作圖形界面沒有提供，只有命令行提供了。當然這是因為沒得選擇。比如清除多餘的 Windows 更新卸載程序只有命令行輸入 dism /online /cleanup-image /startcomponentcleanup /resetbase這樣的方法可以解決，圖形界面貌似是沒法解決，或者只能是麻煩得多的方法。再比如去掉開機密碼但仍然保留鎖屏密碼只有命令行輸入 netplwiz，然後在彈出的對話框里操作，去掉【要使用本計算機，用戶必須輸入用戶名和密碼】的勾。
- 命令行可以用計劃任務來實現定期執行相應的任務，而圖形界面除非開發者有意設計相應的計劃任務功能，否則是做不到的。比如每晚 10 點定時關機，我可以在任務計劃程序里添加一個每晚 10 點運行的C:WindowsSystem32shutdown.exe -s -t 0命令行任務就行了。再比如我添加一個每月執行一次的C:WindowsSystem32dism.exe /online /cleanup-image /startcomponentcleanup /resetbase任務，再也不怕 Windows 更新將我的 C 盤佔滿啦。
- 最後，我並不是【極力推薦】使用命令行的，我只是在說哪些時候命令行相比圖形界面有優勢。
個人來說，喜歡是喜歡，但鼓吹不至於。
我是從mac上慢慢開始學會用命令行的。最初的原因是因為mac的Finder，對於一個從小就使用Windows資源管理器的人來說，一點都不好用。後來由於工作原因學會了一點命令行，便再也回不去。越用，回不去的原因越多，但其實仔細想想也都不是什麼大事：
- 命令行很方便。每個*nix上都有。
- 包管理和腳本。我是一個有系統潔癖的人，從WindowsXP時代開始會因為系統多出了太多自己不認識的東西就重裝系統。而一直以來，裝系統從來都不是最耗時的。最耗時的是折騰環境，一個個網站的去下載自己需要的東西，完了還需要配置。常常一折騰就是一下午。包管理配合腳本，裝機配置就是一鍵搞定。
- 像高贊說的那樣，GUI軟體多數不爭氣。這兩年，我也漸漸不常折騰系統了。而唯一讓我留在命令行里的就是「小而專」的軟體。從13年開始主力使用mac，花了很多錢在App Store裡面尋找應用。但最後用了命令行才知道，App Store裡面的99%的軟體，功能上都只是命令行工具套了層華美的GUI而已。這些工具專是專，但一點都不小。真正麻煩的是，因為沒有pipe和redirection的支持，「專」反而變成了缺點，用起來束手束腳的。
其實也就這些了。實際上，用命令行的人何嘗不想滑鼠點點點，沒人在用CLI瀏覽器不是嗎？
知乎軟吹多（我也被忽悠過），自然黑 *nix 下 bash、管道那一套的也多。雖然 PowerShell 作為下一代 shell 更加牛逼，但是在這個時候總會被選擇性無視掉（不要誤會，我很喜歡 pwsh 的理念，也認為這是進化的方向）。
我很好奇，無腦吹 GUI 的那些人里是不是完全不需要自動化，也不需要組合現有工具以得到符合自己需求的結果。本來各有擅長之處，又不是非此即彼，非要搞得像黨派清算一樣，也不知道這個頭是誰帶起來的。
……管道了解一下。
圖形界面暫時還沒有能匹敵的設計。
命令行的優點需要場景來決定。多媒體編輯還是圖形的天下。
推薦閱讀：
