为什么总有人极力推荐使用命令行操作而非图形界面？

因为其实我们推荐的不是图形界面也不是命令行界面，而是「自动化」。

因为命令行本质上是逻辑的文本化描述。
同样是文本化描述逻辑的还有代码。这也解释了为什么程序员更喜欢命令行。因为一旦逻辑文本化，那么就可以对逻辑进行抽象，保存，优化，很多人不知道命令是可以保存的，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 的那些人里是不是完全不需要自动化，也不需要组合现有工具以得到符合自己需求的结果。本来各有擅长之处，又不是非此即彼，非要搞得像党派清算一样，也不知道这个头是谁带起来的。

……管道了解一下。
图形界面暂时还没有能匹敌的设计。
命令行的优点需要场景来决定。多媒体编辑还是图形的天下。

推荐阅读：