依赖关系管理的关键要素

在软件构建过程中，依赖关系管理是不可忽视的核心因素，尽管团队往往不会在这个问题上投入足够的时间和精力。当提到依赖时，人们通常会想到软件类库和源码等。这些依赖的变化可能对最终的软件产物产生显著影响，不仅在功能和性能方面，还可能表现在诸如目录名称、时间戳等与功能无关的方面。如果依赖管理不当，可能导致软件制品无法正确构建或出现严重问题。

现代软件开发通常涉及多种编程语言，每种语言都有其特定的依赖关系管理工具和方法，这带来了跨语言依赖管理的挑战。例如，一个 Java 程序可能调用由 C++ 开发的动态库，而该动态库又依赖于 Rust 开发的类库。如何在这些不同语言和工具之间建立起全面且准确的依赖关系，是软件工程中必须解决的难题。

除了语言间的依赖关系，还有一些依赖关系是通过构建过程建立起来的，例如通过构建脚本。这些依赖关系通常不会由依赖关系声明文件来维护，而是隐藏在构建过程中的某些步骤中。此外，构建工具和环境等因素通常不被视为依赖，但实际上，它们的变化同样会影响软件制品的稳定性。如果工具缺失、配置错误或存在缺陷，软件制品可能无法正确构建，甚至质量会显著下降。因此，这些传统上不被视为依赖的开发工具也应纳入依赖管理的范畴。

从广义的依赖关系角度来看，依赖管理不仅包括软件库和源码，还涵盖编译器、构建工具、操作系统、系统类库、环境变量、构建脚本等所有可能影响构建结果的要素。基于这一视角，依赖锁文件（lock 文件）需要为每次构建生成，确保每一个构建产物都有其对应的依赖锁文件。这种全面记录所有影响因素的做法，类似于对软件制品进行全面的“白盒化”描述。如果依赖关系保持一致，构建结果也应保持一致；反之，若两个构建产物存在差异，它们的依赖声明必定有所不同。

依赖关系的准确性和全面性直接决定了构建工程的成败。错误的依赖关系可能导致构建失败，而未能全面管理的依赖关系则可能引发构建的不稳定性问题（如常见的“在我电脑上没问题”现象）。构建稳定的工程能力需要掌握准确而全面的依赖关系清单，以简化和优化复杂且成本高昂的工程实践，显著提升软件工程的整体质量和效率。

构建工程中的常见误区

依赖关系的最重要的一个应用场景就是构建。然而，许多团队往往忽视构建工程的重要性，轻视依赖关系管理，从而未能给予构建工程应有的关注。构建工程常被认为是简单且低技术含量的任务，因此通常交由新手程序员负责。然而，由于缺乏经验，这些新人难以为构建工程设计出合理的架构或实现高质量的解决方案。这种对依赖关系管理和构建工程的轻视，直接导致了构建脚本维护成本高、质量低下，流水线不稳定，构建过程频繁出错，甚至难以复现缺陷。即便是经验丰富的开发者，如果不重视构建脚本的质量，认为脚本的编写质量不如 Java、C++ 等代码重要，依然会导致上述问题的出现。工程能力不足的团队通常表现为构建时间过长、构建失败率高、难以定位和解决问题，且无法有效扩展和维护构建系统。这些问题的积累最终显著削弱了团队的整体工程能力。

此外，许多团队过度关注持续集成和流水线管理，甚至为适应流水线而调整构建工程。这种做法实际上是本末倒置。流水线的实现因持续集成环境和基础设施的不同而异，强行让构建去适应流水线只会增加对现有基础设施的耦合度，导致构建工程复杂化、维护成本上升，并使构建质量变得不稳定。相比之下，工程能力强的团队通常由经验丰富的开发者维护构建脚本。这些开发者深刻理解依赖关系管理的重要性，并具备全局视角，能够在设计和实现上做出合理的架构决策。这种做法不仅保障了构建工程的稳定性和高效性，还确保了依赖关系管理的精准性和全面性，从而提升了整体工程能力。此外，优秀的构建工程也具有很高的兼容性和可迁移性，能够轻松适应不同的持续集成流水线以及构建环境。

构建工程的核心角色

软件构建工程是整个软件工程能力的核心，决定了从源码到最终产品的全过程，包括代码检查、分析、编译、测试、打包和发布等任务。例如，在使用 Gradle 的情况下，构建任务涵盖了从代码检查 (lint)、编译 (compile, compileJava)、测试 (check, test) 到打包 (jar, war, package) 和发布 (publish, deploy) 的各个环节。这些任务之间存在紧密的依赖关系，而流水线的实现则是在调用这些构建任务，通过将任务分配给不同的流水线节点，实现高性能、高效率的流水线。

构建工程的质量直接影响着其他工程实践的有效性和质量。持续集成、流水线管理、构建集群、缺陷管理、增量构建、分布式构建、自动化测试和发布管理等工程实践都围绕着构建工程展开。如果构建中的测试极其不稳定或总是失败，即使流水线运行得再高效，其实际价值也会大幅降低。

依赖关系管理的实际应用

当通过精准且全面的依赖关系管理构建出稳定且可重复的构建时，可以在此基础上将其应用于更多场景。例如，可以根据不同的 CI 服务器自动生成构建流水线，实现高精度的增量构建；在代码提交时实时监测依赖变更，甚至在不实际构建的情况下精确对比不同构建产物之间的差异，从而快速识别依赖关系变化的来源。此外，这种依赖关系管理还可以用于漏洞追溯，精准识别漏洞的影响范围和链路，甚至能在秒级时间内分析出一个已知漏洞影响了哪些客户的哪些产品。这种管理方式同样适用于分析架构设计与实现的差异，进一步优化系统设计。

流水线节点的配置实际上反映了构建工程中的任务依赖关系，因此可以通过构建工程中的任务依赖关系推导出流水线结构，甚至自动优化流水线节点的配置。这不仅简化了流水线的设计过程，还确保了其与构建工程的紧密配合，从而最大限度地提高整体工程效率和稳定性。

结语

精准且全面的依赖关系管理不仅包括第三方库或源码的引用，还涵盖操作系统、编译器、构建环境等所有可能影响构建结果的因素。依赖关系是软件构建工程的核心，而软件构建工程又是整个软件工程能力的核心。只有通过正确理解和管理依赖关系，才能构建出高效、稳定的软件工程能力。从依赖关系的精准且全面的管理开始，确保一切有序进行，这正是高效、稳定的软件工程能力的基石。

不过呢，就算是我们对 Bash 语法不熟悉，但我们只是来实现一个简单的功能。Bash 脚本也没写几行，甚至在命令行都一条一条的验证过，放到 Bash 脚本里面运行起来就是会莫名其妙的出错。有些在服务器上的出错根本没法儿在本地重现，本地测试的好好的，刚部署上去也好好的，一到晚上或者假期就是各种出错。所以，有人说这是因为 Bash 这个语言其实不严禁，导致其运行不可靠，不稳定，所以得用 Python。但同样的功能用 Python 实现起来的代码量比 Bash 多，所以只是为了个简单的功能，还是直接写到 Bash 脚本里面吧，在 Python 脚本里面用 os.command 把很多命令一个一个包装起来也是挺烦人的。

从一个简单的例子开始

下面我们就以一个简单的例子来看一下为什么 Bash 脚本会如此不可靠。用 Bash 脚本为 GNU/Linux 实现一个很常见的、也很简单的功能，重启 Tomcat 服务。

Tomcat 是 Java 开发里面很常见的一个服务器应用，安装和使用都很简单。只要系统上已经安装了对应的 JDK，配置好 JAVA_HOME 环境变量，把 Tomcat 下载回来后解压就可以使用了。在 Tomcat 的安装目录里面执行 ./bin/startup.sh 就可以启动 Tomcat 服务，运行 ./bin/shutdown.sh 就可以停止 Tomcat 服务。

如果你读到这里，请稍微暂停来思考一下：如果由你来实现「重启 Tomcat」这个脚本，需要考虑哪些情况呢？

重启 Tomcat 服务，无非就是先「停止」再「启动」就可以了。我们在命令行的 Tomcat 目录下执行了 ./bin/startup.sh 后，打开浏览器验证了 Tomcat 已经启动。然后再执行 ./bin/shutdown.sh，再次打开浏览器发现无法访问了。所以要重启 Tomcat 就是先后执行这两个命令就可以了。

但是有一个要考虑的，如果 Tomcat 已经停止了，再次执行命令来停止 Tomcat 会不会出错呢？我们在命令行下测试了反复执行 ./bin/shutdown.sh 之后，发现除了打印出一个无关紧要的可以被忽略的出错信息后，执行过程并不会出错。

看起来实现重启 Tomcat 这个功能的 Bash 脚本无非就是要做如下几步：1、切换到 Tomcat 的安装目录；2、停止 Tomcat；3、启动 Tomcat。

#!/bin/bash
export JAVA_HOME=/opt/jdk1.8.0_262
export PATH="$JAVA_HOME/bin:$PATH"
cd /home/chaifeng/apache-tomcat-8.5.57
./bin/shutdown.sh
./bin/startup.sh

为了防止 Bash 脚本没有获取到 JAVA_HOME 这个环境变量的设置，我们在脚本里面还额外设置了一下，这又能避免一些奇怪的场景下无法获得这个变量的问题。看起来这个脚本很完美了，在本地也执行了一下，确实如我们期望的 Tomcat 已经重启了。用 ps 命令也确认了重启前后的 java 进程 ID 也发生了变化。

但是当我们把这个脚本部署到服务器上以后，情况却不一样了，大部分时候这个脚本都无法重启 Tomcat。明明 Tomcat 已经运行，但是服务端口处于无法访问的状态，甚至还会出现好几个 Tomcat 进程。难道是 ./bin/shutdown.sh 不起作用吗？当我们登录到服务器上，用 kill -9 杀掉这些 java 进程后，手动执行命令启动 Tomcat，验证没有问题。然后再手动运行命令停止 Tomcat，发现也没问题。更诡异的是，不管我们在命令行反复测试多少次，这两个启动和停止命令都正常工作。

明明在命令行下测试过都正常工作的命令，只有放到 Bash 脚本里面执行才有问题。看来 Bash 脚本的执行确实有时候不知何故的会出问题。难道真的是 Bash 是个不严禁的语言，运行不稳定吗？

为什么连这个简单的 Bash 脚本都运行不稳定？

为什么在命令行下一条一条的执行 Bash 脚本中的命令都没有问题，但是放到一个脚本中执行却会出问题呢？这两种方式下的命令都一样，除了用 Bash 语言不严禁这个理由来解释外，好像也没什么其他原因了。

实际上，有一个很重要的因素很容易被我们所忽略，就是：两条命令执行之间的时间差。

在命令行上手工执行 Tomcat 的停止命令 ./bin/shutdown.sh 后，到输入了启动命令 ./bin/startup.sh 准备按下回车键执行之间，已经过去了好几秒。即使我们是快速复用命令行的历史命令，也要耗费2、3秒。而放到一个脚本里面执行，前一个命令执行结束到下一个命令开始运行，中间大概只有几个毫秒的时间差。几秒与几毫秒的时间差的区别就是这个简单的重启 Tomcat 脚本运行不稳定的根本原因。

当执行了 ./bin/shutdown.sh 来停止 Tomcat，实际上只是给 Tomcat 服务器发送了一个「停止」的信号，然后命令就退出。但此时，Tomcat 收到了「停止」信号后开始运行停止前的清理任务，包括但不限于等待尚未结束运行的客户端连接、释放数据库资源、网络资源、清理临时文件等。所以 Tomcat 还在运行，并没有立刻停止。这个停止运行前的清理工作的耗费时间依据我们的项目不同可能会差别很大，从零点几秒到几十秒，甚至几分钟都有可能。所以，这里是第一个关键的地方，./bin/shutdown.sh 命令执行结束后，Tomcat 可能还在后台进行清理工作，而没有停止运行！

等我们输入了 ./bin/startup.sh 后，时间已经过去了几秒，这个时间差已经足够让 Tomcat 在大多数的情况下真正停止运行了。所以 Tomcat 就又正常启动了。

放在脚本中运行，由于两条命令之间的时间差可能只有几毫秒，这么短的时间不足以让 Tomcat 停止运行。当我们在本地测试运行这个 Bash 脚本时，停止命令和启动命令都已经先后结束运行后。此时在后台，前一个老 Tomcat 进程还尚未结束运行，一个新的 Tomcat 进程就已经启动。但这个新的 Tomcat 可能还需要几秒钟来初始化资源，才能够开始绑定服务端口，这又为老 Tomcat 进程的停止争取到宝贵的几秒时间。当这个新的 Tomcat 结束了资源初始化后开始绑定服务端口的时候，老 Tomcat 可能已经释放了这个服务端口并停止运行。所以在本地测试时，这个重启 Tomcat 的 Bash 脚本表现的非常完美。

当部署到服务器上以后，Tomcat 服务可能会因为资源使用很多而需要更久的时间来释放资源，仅仅几秒是不够的。这就使得当一个新的 Tomcat 结束了资源初始化后，由于老的 Tomcat 服务还没有结束资源释放且没有释放服务端口，导致新的 Tomcat 会因为服务端口被占用而启动失败。

这就是为什么这么简单的一个重启 Tomcat 的 Bash 脚本会出现运行不稳定的原因。而且也不会因为我们用 Python 重写这个 Bash 脚本就可以解决这个问题。

让这个简单的例子变的稳定

既然找到了原因，那就好说了，启动 Tomcat 之前先把现有的 Tomcat 进程杀掉。因为 Tomcat 本身是一个 Java 应用，所以也就是杀掉 java 进程。

现在的问题是「如何杀掉进程」。有人会说这很简单啊，用 kill -9 就可以杀掉进程。没错，这样的确可以。而且如果大家去搜索「Linux 杀掉进程」，很多的搜索结果都提到要用 kill -9 来杀掉进程。为什么要使用选项 -9 呢？有人会说，因为有时候直接用 kill 命令杀不掉进程，反复执行也杀不掉，用了选项 -9 之后就可以了。

事实上，kill -9是对系统危害最大的命令之一。也有人会说，我一直用 kill -9 来杀进程，也从来没破坏过系统啊。这是典型的幸存者偏差，就跟开车不系安全带、骑车不带头盔一样，确实有很多人不系安全带不带头盔，也没见过出事儿。但是只要发生一次，那就是严重伤害。

直接用 kill 命令去杀一个进程，默认是给进程发送了 SIGTERM 信号，当进程收到这个终止信号后，可能会开始终止前的清理工作。当清理工作结束后，该进程就会自行终止，如果不需要清理就直接结束了。如果清理时间稍微长一些，就会让我们产生 kill 命令不工作的错觉。但我们可能只要稍微多等待几秒，进程就会结束了。而使用 kill -9 则类似于一枪爆头，没有给进程在自杀前善后工作的机会。如果进程打开了很大的文件，或者正在写入数据库。暴力终止进程的执行是很有可能会导致文件或者数据库的损坏。

作为一名称职的司机，我们一定会系安全带的。作为一名称职的运维工程师，一定不会滥用 kill -9 这个命令的。现在抬头看看你的周围，有多少不称职的运维工程师呢？

既然在执行了停止 Tomcat 的命令后，不能立即强行终止 java 进程，那就需要等待。很显然，我们不能预计要等待多久。如果固定的等待一个比较长的时间，而 Tomcat 早已经停止，这就会让别人觉得这个 Bash 脚本的性能太差了。现在我们修改一下这个重启 Tomcat 的 Bash 脚本：

#!/bin/bash
export JAVA_HOME=/opt/jdk1.8.0_262
export PATH="$JAVA_HOME/bin:$PATH"
cd /home/chaifeng/apache-tomcat-8.5.57
./bin/shutdown.sh
for ((i=0;i<60;i++)); do
    pgrep java || break
    sleep 1
done
pgrep java | xargs --no-run-if-empty kill -9
./bin/startup.sh

新增了一个等待循环，每秒钟都检查一下 java 进程，如果没找到就终止循环，最多等待 60 秒。退出循环后，再次查找 java 进程，这里用了 GNU xargs 的选项 -—no-run-if-empty 可以避免 xargs 没有从管道接受了数据而去执行 kill -9 命令，导致无谓的出错。

到这里，这个简单的重启 Tomcat 的 Bash 脚本看上去没啥问题了，不管是本地还是服务器上都可以正常的稳定的工作了。而且我们应该也要注意到，讨论的这个问题不管我们用 Python 还是 Bash 还是其他什么语言来实现这个功能，都同样是需要考虑的。要承认，这个造成 Bash 脚本运行不稳定的原因与 Bash 一点儿关系都没有。

这个简单的例子还没有结束

看到这里，或许有人会疑惑还需要考虑什么呢？停止 Tomcat 后，如果在 60 秒内 Tomcat 还没有停止就会强制停止，然后再启动 Tomcat。完美，没什么要考虑的了。

如果在系统上除了 Tomcat 这个 java 进程外，还有其他的 Java 进程，我们怎样确保这个重启脚本不会杀掉其他无关的 Java 进程呢？

如果 Tomcat 是以某个特定用户来运行，如何阻止其他用户无意中执行这个脚本呢？

如果系统上运行了多个 Tomcat 实例，如果确保这个重启脚本只会重启特定的 Tomcat 而不是其他的 Tomcat 服务呢？

如何能够让不同的 Tomcat 复用同一个重启脚本，而不用是为每个 Tomcat 的安装实例复制多份脚本呢？

如何让这个脚本自动判断 Tomcat 版本并选择对应的 JDK？以避免使用错误的 JDK 来启动 Tomcat 呢？

如何让这个重启脚本自动判断当前目录是否位于一个 Tomcat 安装目录中，运行后重启的就是这个 Tomcat，这样就避免了每次使用可能需要传入 Tomcat 目录作为参数了。万一输入了错误的目录呢？

如何避免使用特权用户执行这个脚本来重启 Tomcat？否则不仅会引入额外的安全风险，也会让因一些文件所有者发生变化而导致非特权用户以后无法再管理 Tomcat。

如何让每次重新开机后可以自动执行这个脚本来重启 Tomcat？如果要做开机自动启动脚本，是不是还要考虑 System V 还是 Systemd ？

作为开机的自动启动脚本时，如何自动判断 Tomcat 的所属用户，并自动切换到该用户的权限下执行？这样可以避免无谓的启动配置。

如果 Tomcat 上部署的服务依赖其他的服务，比如 MySQL，如何让这个脚本自动判断依赖的服务已经运行？避免 Tomcat 启动后服务运行后失败

如何让重启脚本判断 Tomcat 重启后服务已经成功运行，否则将以某种方式发出通知？这样就避免了重启不成功，但是我们不知道。

如何避免这个脚本互斥运行？以防止这个脚本在不同的终端上分别同时运行而导致的运行冲突。

如何避免远程登录到一个服务器上运行了脚本，并确认 Tomcat 运行正常，结果退出登录后，Tomcat 服务也会终止运行的问题。

等等……等等……

为了写出一个稳定、可靠、易用的 Tomcat 重启脚本，我们有很多要考虑的事情。列出了这么多可能需要考虑的问题，有哪个问题是和 Bash 有关的？很显然没有。如果我们用 Python 去开发这样一个功能，是否也需要考虑这些问题呢？答案是肯定的。

结论，Bash 脚本不稳定的原因其实就是我们自己。用 Python 重写 Bash 脚本后，原先该有的问题还是存在，只是我们不能再怪罪是 Python 这个语言不严谨，Python 运行不稳定了。只能乖乖从我们自身去寻找问题，然后慢慢得以解决。

如果一开始我们就能够清楚的意识到我们对于一些基础技能的欠缺，就可以提前避免很多不该有的问题。比如对 Bash 的语法不熟悉，也存在很多的误解，那我们怎么能写好 Bash？缺乏对于操作系统的一些功能理解，比如滥用 SIGKILL 信号，不明白什么时候该忽略 SIGHUP 信号等等，那我们怎么能管理好系统？其次，我们缺乏一个系统的运维知识体系，认为运维工作就是去使用一个又一个的工具，不理解这些工具在运维知识体系中的位置。那我们如何能够有效的利用这些不同工具的组合来解决问题呢？再者，我们缺乏从全局系统角度去思考问题，解决了一个又冒出另一个。或者就没明白这些不同的问题之间可能存在一个共同的根因，总是就问题解决问题，那我们要浪费多少时间和人力才可以维护好一个系统？最后，做好运维工作，提升运维技能不只是运维工程师才需要掌握的。对于开发工程师也有提升自己工作效率，更有效的与运维团队协作和沟通，无论是对自己、对团队、对项目都有好处。

要想了解运维工作的知识体系以及技术脉络请看DevOps 技术栈。再看看你是否也有关于 Bash 的 10 个常见误解？要想写出可靠稳定的 Bash 脚本，那一定要写Bash 脚本的单元测试。

因为 Bash 脚本通常都是在执行一些与操作系统有关的操作，可能会对运行环境造成一些不可逆的操作，比如修改或者删除文件、升级系统中的软件包等。所以为了确保 Bash 脚本的安全可靠，在生产环境中部署之前一定需要做好足够的测试以确保其行为符合我们的预期。

如何能够安全可靠的去测试 Bash 脚本呢？有人可能会说我们可以用 Docker 容器。是的，这样做即安全又方便。在容器隔离出来的环境中不用担心脚本会破坏我们的系统，而且也能非常简单的快速重建出一个可用的测试环境。

不过呢，请考虑以下的几个常见的场景：

场景一：在执行 Bash 脚本测试前，我们需要需要事先安装好所有在 Bash 脚本中会用到的第三方工具，否则这些测试将会因为命令找不到而执行失败。例如，我们在脚本中使用了 Bazel 这个构建工具。我们必须提前安装并配置好 Bazel，而且不要忘记为了能够正常使用 Bazel 还得需要一个支持使用 Bazel 构建的工程。

场景二：测试结果的稳定性可能取决于脚本中访问的第三方服务的稳定性。比如，我们在脚本中使用 curl 命令从一个网络服务中获取数据，但这个服务有时候可能会访问失败。有可能是因为网络不稳定导致的，也可能是因为这个服务本身不稳定。再或者如果我们需要第三方服务返回不同的数据以便测试脚本的不同分支逻辑，但我们可能很难去修改这个第三方服务的数据。

场景三：Bash 脚本的测试用例的执行时间取决于脚本中使用的命令的执行时间。例如，如果我们中脚本中使用了 Gradle 来构建一个工程，由于不同的工程大小 Gradle 的一个构建可能要执行3分钟或者3个小时。这还只是一个测试用例，如果我们还有20个或者100个测试用例呢？我们是否还能在几秒内获得测试报告呢？

即使使用了容器来执行 Bash 脚本测试，也一样无法避免上面的几个问题。环境的准备过程可能会随着测试用例的增多而变的繁琐，测试用例的稳定性和执行时长取决于第三方命令和服务的稳定性和执行时长，还可能很难做到使用不同数据来覆盖不同的测试场景。

对于测试 Bash 脚本来说，我们真正要验证的是 Bash 脚本的执行逻辑。比如在 Bash 脚本中可能会根据传入的参数来组合出内部所调用的命令的选项和参数，我们要验证的是这些选项和参数确实如我们预期的。至于调用的命令在接受了这些选项和参数后由于什么原因而失败，可能我们并不关心这所有的可能原因。因为这会有更多的外部影响因素，比如硬件和网络都是否工作正常、第三方服务是否正常运行、构建工程所需的编译器是否安装并配置妥当、授权和认证信息是否都有效、等等。但对于 Bash 脚本来说，这些外部原因导致的结果就是所调用的命令执行成功或者失败了。所以 Bash 脚本只要关注的是脚本中调用的命令是否能够成功执行，以及命令输出了哪些，并决定随后执行脚本中的哪些不同分支逻辑。

如果说我们就是想知道这个命令搭配上这些选项参数是否能按我们预期的那样工作呢？很简单，那就单独在命令行里面去执行一下。如果在命令行中也不能按预期的工作，放到 Bash 脚本里面也一样不会按预期的工作。这种错误和 Bash 脚本几乎没什么关系了。

所以，为了尽量去除影响 Bash 脚本验证的那些外部因素，我们应该考虑为 Bash 脚本编写单元测试，以关注在 Bash 脚本的执行逻辑上。

什么样的测试才是 Bash 脚本的单元测试？

首先，所有存在于 PATH 环境变量的路径中的命令都不应该在单元测试中被执行。对 Bash 脚本来说，被调用的这些命令可以正常运行，有返回值，有输出。但脚本中调用的这些命令都是被模拟出来的，用于模拟对应的真实命令的行为。这样，我们在 Bash 脚本的单元测试中就避免了很大一部分的外部依赖，而且测试的执行速度也不会受到真实命令的影响了。

其次，每个单元测试用例之间都应该是独立的。这意味着，这些测试用例可以独立执行或者被任意乱序执行，而不会影响验证结果。

最后，这些测试用例可以在不同的操作系统上执行，且都应该得到相同的验证结果。比如 Bash 脚本中使用了只有 GNU/Linux 上才有的命令，对应的单元测试也可以在 Windows 或者 macOS 上执行，且结果一致。

怎样为 Bash 脚本写单元测试？

与其他编程语言一样，Bash 也有多个测试框架，比如 Bats、Shunit2 等，但这些框架实际上并不能隔离所有 PATH 环境变量中的命令。有一个名为 Bach Testing Framework 的测试框架是目前唯一一个可以为 Bash 脚本编写真正的单元测试的框架。

Bach Testing Framework 的最独特的特性就是默认不会执行任何位于 PATH 环境变量中的命令，因此 Bach Testing Framework 非常适用于验证 Bash 脚本的执行逻辑。并且还带来了以下好处：

• 简单
  什么也不用安装。我们就可以执行这些测试。比如可以在一个全新的环境中执行一个调用了大量第三方命令的 Bash 脚本。
• 快
  因为所有的命令都不会被真正执行，所以每一个测试用例的执行都非常快。
• 安全
  因为不会执行任何外部的命令，所以即使因为 Bash 脚本中的某些错误导致执行了一个危险的命令，比如 rm -rf *。Bach 会保证这些危险命令不会被执行。
• 与运行环境无关
  可以在 Windows 上去执行只能工作在 GNU/Linux 上的脚本的测试。

由于操作系统和 Bash 的一些限制，Bach Testing Framework 无法做到：

• 拦截使用绝对路径调用的命令
  事实上我们应该避免在 Bash 脚本中使用绝对路径，如果不可避免的要使用，我们可以把这个绝对路径抽取为一个变量，或者放入到一个函数中，然后用 @mock API 去模拟这个函数。
• 拦截诸如 >、>>、<< 等等这样的 I/O 重定向
  是的，无法拦截 I/O 重定向。我们也同样可以把这些重定向操作隔离到一个函数中，然后再模拟这个函数。

Bach Testing Framework 的使用

Bach Testing Framework 需要 Bash v4.3 或更高版本。在 GNU/Linux 上还需要 Coreutils 和 Diffutils，在常用的发行版中都已经默认安装好了。Bach 在 Linux/macOS/Cygwin/Git Bash/FreeBSD 等操作系统或者运行环境中验证通过。
– Bash v4.3+
– Coreutils (GNU/Linux)
– Diffutils (GNU/Linux)

安装 Bach Testing Framework

Bach Testing Framework 的安装很简单，只需要下载 https://github.com/bach-sh/bach/raw/master/bach.sh 到你的项目中，在测试脚本中用 source 命令导入 Bach Testing Framework 的 bach.sh 即可。

比如：

source path/to/bach.sh

一个简单的例子

与其它的测试框架不同，Bach Testing Framework 的每一个测试用例都是由两个 Bash 函数组成，一个是以 test- 开头的测试执行函数，另一个是同名的以 -assert 结尾的测试验证函数。

比如在下面的例子中，有两个测试用例，分别是
– test-rm-rf
– test-rm-your-dot-git

一个完整的测试用例：

#!/usr/bin/env bash
set -euo pipefail

source bach.sh # 导入 Bach Testing Framework

test-rm-rf() {
    # Bach 的标准测试用例是由两个方法组成
    #   - test-rm-rf
    #   - test-rm-rf-assert
    # 这个方法 `test-rm-rf` 是测试用例的执行

    project_log_path=/tmp/project/logs
    sudo rm -rf "$project_log_ptah/" # 注意，这里有个笔误！
}
test-rm-rf-assert() {
    # 这个方法 `test-rm-rf-assert` 是测试用例的验证
    sudo rm -rf /   # 这就是真实的将会执行的命令
                    # 不要慌！使用 Bach 测试框架不会让这个命令真的执行！
}

test-rm-your-dot-git() {
    # 模拟 `find` 命令来查找你的主目录下的所有 `.git` 目录，假设会找到两个目录

    @mock find ~ -type d -name .git === @stdout ~/src/your-awesome-project/.git \
                                                ~/src/code/.git

    # 开始执行！删除你的主目录下的所有 `.git` 目录！
    find ~ -type d -name .git | xargs -- rm -rf
}
test-rm-your-dot-git-assert() {
    # 验证在 `test-rm-your-dot-git` 这个测试执行方法中最终是否会执行以下这个命令。

    rm -rf ~/src/your-awesome-project/.git ~/src/code/.git
}

Bach 会分别运行每一个测试用例的两个方法，去验证两个方法中执行的命令及其参数是否是一致的。比如，第一个方法 test-rm-rf 是 Bach 的测试用例的执行，与之对应的测试验证方法就是 test-rm-rf-assert 这个方法

在第二个测试用例 test-rm-your-dot-git 中使用了 @mock API 来模拟了命令 find ~ type d -name .git 的行为，这个命令用来找出用户目录下的所有 .git 目录。模拟之后，这个命令并不会真的执行，而是利用了 @stdout API 在标准终端上输出了两个虚拟的目录名。

然后我们就可以执行真正的命令了，将 find 命令的输出结果传递给 xargs 命令，并组合到 rm -rf 命令之后。

在对应的测试验证函数 test-rm-your-dot-git-assert 里面就验证是 find ~ -type d -name .git | xargs -- rm -rf 的运行结果是否等同于命令 rm -rf ~/src/your-awesome-project/.git ~/src/code/.git

@mock 是 Bach Testing Framework 中很重要的一个 API，利用这个 API 我们就可以模拟 Bash 脚本中所使用的任意命令的行为或者输出。

比如

@mock curl --silent google.com === \
    @stdout "baidu.com"

模拟了命令 curl --silent google.com 的执行结果是输出 baidu.com。在真实的正常场景下，我们是无法做到访问 google.com 得到的是 baidu.com。这样模拟之后就可以用来验证 Bash 脚本中处理一个命令不同响应时的行为了。

@mock API 甚至还支持更复杂的行为模拟，我们可以自定义一个复杂的模拟逻辑，比如：

@mock ls <<\CMD
    if [[ "$var" -eq 1 ]]; then
        @stdout one
    else
        @stdout others
    fi
CMD

在这个模拟中，会根据变量 $var 的值来决定命令 ls 的输出 one 还是 others。

用 @mock API 模拟的命令在任何时候执行的时候都是同样的行为。但如果要模拟同一个命令重复执行的时候要返回不同的值，Bach Testing Framework 还提供了一个 @@mock 这个 API，比如：

@@mock uuid === @stdout aaaa-1111-2222
@@mock uuid === @stdout bbbb-3333-4444
@@mock uuid === @stdout cccc-5555-6666

这三个模拟命令模拟了 uuid 在重复执行三次的时候都返回不同的结果，按照模拟的先后顺序分别输出对应的模拟输出。如果在执行完所有的模拟输出后，再重复执行将会始终输出最后一个模拟的输出。

更详细的 API 介绍请在 Bach Testing Framework 的官网 https://bach.sh 查看。

使用 Bach Testing Framework 还可以让我们更安全方便的练习 Bash 编程。

比如，我们希望实现一个函数 cleanup 用来删除参数上指定的文件。一个实现可能是：

function cleanup() {
    rm $1
}

这个函数的实现其实是有安全问题的，因为对于 Bash 来说，有没有把一个变量用双引号包含起来是非常重要的。在这个实现中，变量 $1 就没有用双引号，这会带来严重的后果。下面我们将使用 @touch API 来创建几个文件，其中将有一个文件名中含有特殊字符 的文件 bar。我们都知道，对于含有特殊字符的文件名是要放入到双引号中的。现在这个这个 cleanup 的实现里面没有使用双引号，但是传参的时候使用了双引号，那是否还会按照我们的预期来执行呢？

function cleanup() {
    rm -rf $1
}

test-learn-bash-no-double-quote-star() {
    # 创建了三个文件，其中有一个名为 "bar*" 的文件
    @touch bar1 bar2 bar3 "bar*"

    # 要删除这个错误的文件名 bar*，而不删除其他文件，使用了双引号来传参，这是正确的
    cleanup "bar*"
}

test-learn-bash-no-double-quote-star-assert() {
    rm -rf "bar*"
}

这个测试用例将会失败，从验证结果中我们可以看到，期望只删除文件 bar，但是在函数 cleanup 里面，因为遗漏了双引号，会导致变量被二次展开。实际执行的命令是 rm -rf "bar*" bar1 bar2 bar3。

现在修复函数 cleanup，把变量 $1 放入双引号：

function cleanup() {
    rm -rf "$1"
}

再次执行测试，会发现确实执行的是命令 rm -rf "bar*"。

Bach Testing Framework 目前已经在宝马集团和华为内部使用了。在宝马集团的一个有数千人规模的大型项目里，Bach Testing Framework 保证了数个非常重要的构建脚本的维护。这些脚本的可靠性和稳定性决定了数千人团队的工作效率，现在就可以在本地快速验证这些构建脚本的执行逻辑，也避免了在本地很难复现一些构建集群中的特殊场景的问题。

如果大家在使用上有啥问题和建议可以去Bach 测试框架的项目上留言。

即使为 Bash 脚本写了单元测试后，我们可能还会遇到为什么 Bash 脚本总是不稳定？难道真的是 Bash 不严禁不稳定吗？另外还有《关于 Bash 的 10 个常见误解》，看看你有多少误解。以及在学习和掌握运维技术栈时，除了 Bash 以外可能还要学有很多工具，比如 Python、Ansible、Kubernetes等等。这些工具在运维技术栈里处于什么位置，他们之间的关系又是如何呢？我们是应该学 Bash 还是 Python 还是 Ansible 呢？请看《DevOps 技术栈》这个我认为最重要的一篇文章以建立起我们的运维技术脉络。

其实 Bash 的语法是图灵完备的，也就是说理论上我们可以用 Bash 实现任何其他语言可以实现的功能。话虽如此，但不同的语言有其业务场景的适用性，我们当然应该把 Bash 用在最适合的场景下，这才能发挥出 Bash 的强大威力。

完全没有道理用自己熟悉的编程语言去比较其他语言，如果不符合自己熟悉的习惯就评价为怪异。作为程序员一定要保持开放的心态去学习。

这篇文章介绍了大家对 Bash 的常见误解，看看你知道多少？

Bash 的 if 语句后面其实不是括号

这应该是被人误解最多的，吐槽最多的一点。比如 Bash 的语法非常怪异，if 后面的括号竟然是方括号，而且括号的前后都要有空格！

事实上，Bash 的 if 语法定义上其实并没有定义括号，而且命令序列。执行命令 help if 可以看到 if 的使用方法

if COMMANDS; then COMMANDS; 
[ elif COMMANDS; then COMMANDS; ]... 
[ else COMMANDS; ] 
fi

实际上所谓的方括号 [ 其实是一个命令，这个命令既是 Bash 的内建命令，也是一个外部命令，根据系统的不同可能位于 /bin 或者 /usr/bin 目录下。比如 macOS 上执行命令 ls -l “/bin/[” 就可以找到。

当我们知道了方括号 [ 是个命令后，这些怪异的语法就变得很容易理解了。因为 if 后面是命令，所以当然也可以用方括号 [ 命令了。既然这是一个命令，那命令的参数和命令本身自然也需要有空格来做分割了。事实上方括号 [ 命令等同于 test 命令，但是要求命令的最后一个参数必须是 ]。哈哈，如果一个括号只有开头而没有结尾，这才是最怪异的呢。

不过还有一种常见的是双方括号 [[，这个是 Bash 的内建关键字。虽然可以把关键字当作命令来看到，但是 Bash 会对关键字做特殊处理。比如在 [[ 与其结尾参数 ]] 之间是可以使用 &&、|| 这样的逻辑操作的，如果我们把 [[ 1 -eq 1 && 2 -eq 2 ]] 当作两条命令来看到，第二个命令是 2，这肯定会执行失败了。这就是 Bash 对关键字做的一个特殊处理。而 [ 是一个命令，不管是内建命令也好外部命令也好，[ 1 -ne 0 && 2 -ne 3 ] 一定会出错的，因为这将执行两条命令，第一条 [ 1 -ne 0 将会因为 [ 命令的最后一个参数不是 ] 而出错，第二条命令 2- ne 3 ] 可能将会因为在 PATH 环境变量中没有找到一个名为 2 的命令而出错。

说到这里，我们可以想想看。假如有一个 Java 程序员竟然对 Java 的 if 语句的语法不熟悉，这个程序员怎么可能写出好的 Java 程序？把 Java 换成 Bash 也是一样的。

真的无法阻止 Bash 中的函数修改全局的变量吗？

这应该是第二个被人误解最多的一个 Bash 特性，也常被用来证明 Bash 的语言多么不可靠。原因是如果在函数中没有使用 local 关键字来声明变量，那函数里的变量将会对全局产生影响。或许看起来有些绕口，请看如下的例子：

#!/usr/bin/env bash
x=42
bar=answer

function foo() {
  local x=999
  bar=world
  echo foo: x=$x bar=$bar
}

foo
echo x=$x bar=$bar

执行的结果是

foo: x=999 bar=world
x=42 bar=world

在函数 foo 中用 local 关键字声明了变量 x，这使得函数内变量 x 的作用域限于函数 foo 内，不同于外部的全局变量 x。而函数内使用变量 bar 时没有用 local 关键字声明，这使得函数内对变量 bar 的赋值实际上是修改了函数之外的变量 bar。这可能会造成我们在编写函数的时候，必须显式的使用 local 关键字来声明局部变量，否则会发生无意中使用了全局的同名变量，导致该全局变量被无意中修改的问题。

这个问题真的很严重，也的确是有些人吐槽 Bash 不严谨的地方之一。事实上，这也恰巧说明了我们可能并不了解 Bash 中定义函数的语法。

大家都知道，在 Bash 中定义函数时，把函数体放到花括号中。看上去这点和很多编程语言也非常类似，比如 C、Java 等。但却不会把变量的作用域限制在花括号的范围内。其实 Bash 中声明函数时，其语法要求函数体是一个组合命令即可。所以，花括号并不是必须的，我们还可以用圆括号。请看下面的例子中函数 foo 的函数体用了圆括号：

#!/usr/bin/env bash
x=42
bar=answer

function foo() ( # <--
  local x=999
  bar=world
  echo foo: x=$x bar=$bar
) # <--

foo
echo x=$x bar=$bar

执行的结果是：

foo: x=999 bar=world
x=42 bar=answer

在第二个例子中，我们把函数体放到了圆括号里面，这使得这个函数将会在子进程中执行。而子进程是无法修改父进程中的任何变量的。所以，即使在函数中没有用 local 关键字声明变量 bar，对这个变量的变更也不会影响到全局的同名变量。

因为在定义 Bash 的函数时需要的是组合命令，所以下面的函数定义也是合法的：

function foo()
for param; do
  echo "=> $param";
done

执行 foo a b c 会得到

=> a
=> b
=> c

是的，出乎大家的意料，定义 Bash 函数的时候连什么括号都可以不要。

所以，我想再吐槽一次。如果有人连 Bash 的语法都不了解不熟悉，有很多的误解。他们是如何得出 Bash 的语法不严禁，功能不如其他语言这些结论的？

Bash 也支持直接执行目录名来切换到该目录中

很多使用 Zsh 的用户在举例 Zsh 与 Bash 的区别时，这是一个常用来对比的特性。很可惜，这不是 Zsh 的独特特性，Bash 其实也支持。实际上 Zsh 下这个特性也是默认关闭的，只是很多人都会使用 Oh My Zsh 这个知名的配置工程，而 Oh My Zsh 默认开启了这个特性。在 Bash 下开启这个特性的命令是 shopt -s autocd，开启之后我们就可以直接执行目录名来切换到该目录了。

Bash 其实也支持 ** 通配符来匹配多级子目录

这个特性也是有些人会误认为 ** 通配符是 Zsh 比 Bash 好用的一个特性，但其实 Bash 也是支持的。

开启命令是 shopt -s globstar

然后我们就可以用 ls **/*.txt 来列出当前目录及其子目录下的所有 *.txt 文件了。

所以，以后也请不要那这个特性来对比 Zsh 和 Bash 了。

Bash 在命令行上其实也支持撤销、粘贴等操作

当然有很多人知道在命令行下如何快速跳转光标、删除单词或者删除到行尾等常用操作，但很少有人会知道的 Bash 在命令行也支持撤销、粘贴等操作，而且粘贴功能事实上比操作系统默认的更强大。

撤销的快捷键是 Ctrl-/，反复按下会继续撤销之前的操作。

粘贴的快捷键是 Ctrl-y。当在命令行使用了 Ctrl-k 删除到行尾、Ctrl-w 删除前一个单词、Alt-d 删除下一个单词、Ctrl-u 删除整行等操作后，Bash 会将删除掉的内容放到自己的剪贴板中。要注意的是这个 Bash 的剪贴板不同于操作系统的剪贴板。删除之后，可以按下 Ctrl-y 在当前光标处粘贴最后一次删除的内容，重复按下会重复粘贴。

如果删除过多次，按下 Ctrl-y 粘贴出最后一次删除的内容后，再紧接着按下 Alt-y 就会替换为前一次的内容，重复按下 Alt-y 会继续替换更早之前删除的历史内容。

Bash 中使用 I/O 重定向的时候，重定向可以不用放在命令的最后

我们经常使用 >、>>、<、<< 来把命令结果保存到文件、或者从文件中读取内容。通常我们都是把重定向放在命令的最后。比如 ls -ld * >/tmp/files.txt

实际上，重定向可以位于一条命令的任何位置，放在中间或者最前面都是可以的。比如以下命令都是一样的

>/tmp/files.txt ls -ld *

ls >/tmp/files.txt -ld *

有时候不把重定向放在命令的最后会给我们快速复用并修改之前的命令非常方便。比如我们只需要快速搜索到之前执行的命令 >/tmp/files.txt ls -ld *，就可以很容易的修改最后一个参数了。

顺便说以下，看上去 Bash 中的 I/O 重定向很简单、很易使用。但事实上Bash 的 I/O 重定向比绝大多数人认为的更强大且复杂。或许我会在另外的文章中来详细介绍一下。

Bash 支持直接访问网络

Bash 的网络功能是很多人不知道的一个特性，不需要什么 nc、socat 这些命令就可以访问网络资源。只需要使用 I/O 重定向直接访问设备文件 /dev/tcp/<host>/<port> 即可，把 <host> 和 <port> 换成你希望访问的网络地址和端口。比如 /dev/tcp/baidu.com/80 就是访问主机 baidu.com 的 80 端口。

请看下面的命令，用 Bash 的内建命令实现了一个简单的 HTTP 客户端功能，访问 baidu.com 并打印出响应。

#!/usr/bin/env bash
exec 6<>/dev/tcp/baidu.com/80;
printf "GET / HTTP/1.1\nHOST: baidu.com\nConnection: close\n\n" >&6;
while read -r -u 6 line; do
  echo "$line";
done;
exec 6>&-

执行结果

HTTP/1.1 200 OK
Date: Sat, 08 Aug 2020 23:31:36 GMT
Server: Apache
Last-Modified: Tue, 12 Jan 2010 13:48:00 GMT
ETag: "51-47cf7e6ee8400"
Accept-Ranges: bytes
Content-Length: 81
Cache-Control: max-age=86400
Expires: Sun, 09 Aug 2020 23:31:36 GMT
Connection: Close
Content-Type: text/html

<html>
<meta http-equiv="refresh" content="0;url=http://www.baidu.com/">
</html>

其他的 Shell，比如 Zsh、Sh 等可能不支持这种直接访问网络的方式，但是 Zsh 的网络支持其实更强大，只是方式不同。

Bash 的受限模式让自动化运维更安全

在启动 Bash 的时候，使用选项 -r 可以让 Bash 进入受限模式。在受限模式下，会有很多的限制，比如：

• 不能用 cd 命令切换目录
• 不能修改 PATH 环境变量
• 不可以通过指定路径的方式来运行命令
• 不能使用 I/O 重定向
• ……

Bash 受限模式的一个常见的使用场景是自动化运维。想想看，如果系统会根据一些用户的请求来自动生成并执行一些命令，在这些命令中可能会使用一些用户的输入，这可能会产生类似 SQL 注入的漏洞攻击。再比如，在一些自动化运维的时候难免要临时切换到特权用户下执行命令。为了让系统更安全，在临时的特权用户环境里面只能执行一些特定的命令或者脚本，以尽量减少系统被攻击的可能性。使用 Bash 的受限模式就可以避免非期望的命令或者脚本被执行，让系统更加安全。

有些「Bash 命令」其实和 Bash 无关

或许有的人会把 ls、rm、mkdir、…… 等命令称为 Bash 命令，其实这些命令与 Bash 并没有关系。比如在 GNU/Linux 上，这些命令属于 GNU Coreutils 这个项目。而 Bash 命令应该是 Bash 的内建命令，比如 alias、exec、printf 等等。有些 Coreutils 中的命令因为使用的很多，为了避免无谓的进程创建开销，所以 Bash 也将其内建了，比如 echo、test 等。不过要注意的是，Bash 的内建命令的选项与 Coreutils 中的同名命令可能不同。

比如执行下列命令可能会得到不同的结果：

echo --help
/bin/echo --help

# macOS 上用 brew install coreutils 后的默认路径
/usr/local/opt/coreutils/libexec/gnubin/echo --help

我们也能够为 Bash 写单元测试

Bash 还有一个最易被人诟病的一点就是，很难去测试一个 Bash 脚本。所以这也是很多人说应该用 Python 代替 Bash 的一个理由，因为我们可以为 Python 写单元测试，而不能为 Bash 写单元测试。虽然已经有了一些 Bash 的测试框架，比如 Bats、shunit2 等。但这些测试框架都是集成测试框架。这意味着，为了执行 Bash 脚本的测试用例，我们需要事先安装好被测脚本中依赖的各种工具，配置好所需的目录、配置等。比如在我们的脚本中使用了 Bazel 或者 CMake，如果没有安装 Bazel 或者 CMake，很显然这些测试都将失败。

如果可以为 Bash 脚本写单元测试，这就意味着这些测试可以在任意时候、任意的机器上乱序执行任意的测试都应该在秒级的时间内得到相同的执行结果。无论是在 Windows 上执行 GNU/Linux 的 Bash 脚本的单元测试，还是在一个全新的极简的环境中执行一个使用了很多第三方工具的复杂的 Bash 脚本的单元测试，都应该得到稳定的测试结果。

现在有一个名为 Bach 的测试框架（Bach Testing Framework），这是目前唯一的一个真正可以为 Bash 脚本编写单元测试的框架。Bach 测试框架的独特之处在于它不会执行任何在 PATH 环境变量中的命令，而且还提供了丰富的模拟命令用于模拟其它命令的行为。Bach 测试框架非常适合于测试 Bash 脚本的执行逻辑，而不用实现安装并配置好被测脚本中使用到的各个工具。

请看下面的例子：

#!/usr/bin/env bash
set -euo pipefail
source bach.sh

test-rm-rf() {
    # Write your test case

    project_log_path=/tmp/project/logs
    sudo rm -rf "$project_log_ptah/" # 这里写错了变量名，导致了一个严重的错误
}
test-rm-rf-assert() {
    # Verify your test case
    sudo rm -rf /   # 这就是将要执行的命令
                    # 别慌！Bach 不会让这个命令真的执行！
}

Bach 测试框架的每一个测试用例默认是由两个函数来组成，一个是用于编写测试用例，比如上例中的 test-rm-rf，与之对应的是用于验证测试结果的测试验证函数 test-rm-rf-assert。Bach 测试框架会分别运行这两个函数，并对比执行中调用的命令序列是否一致。

请直接看解决 UFW 和 Docker 的问题。

问题

UFW 是 Ubuntu 上很流行的一个 iptables 前端，可以非常方便的管理防火墙的规则。但是当安装了 Docker，UFW 无法管理 Docker 发布出来的端口了。

具体现象是：

1. 在一个对外提供服务的服务器上启用了 UFW，并且默认阻止所有未被允许的传入连接。
2. 运行了一个 Docker 容器，并且使用 -p 选项来把该容器的某个端口发布到服务器的所有 IP 地址上。比如：docker run -d --name httpd -p 0.0.0.0:8080:80 httpd:alpine 将会运行一个 httpd 服务，并且将容器的 80 端口发布到服务器的 8080 端口上。
3. UFW 将不会阻止所有对 8080 端口访问的请求，用命令 ufw deny 8080 也无法阻止外部访问这个端口。

这个问题其实挺严重的，这意味着本来只是为了在内部提供服务的一个端口被暴露在公共网络上。

在网络上搜索 “ufw docker” 可以发现很多的讨论：

• https://github.com/moby/moby/issues/4737
• https://forums.docker.com/t/running-multiple-docker-containers-with-ufw-and-iptables-false/8953
• https://www.techrepublic.com/article/how-to-fix-the-docker-and-ufw-security-flaw/
• https://blog.viktorpetersson.com/2014/11/03/the-dangers-of-ufw-docker.html
• https://askubuntu.com/questions/652556/uncomplicated-firewall-ufw-is-not-blocking-anything-when-using-docker
• https://chjdev.com/2016/06/08/docker-ufw/
• https://askubuntu.com/questions/652556/uncomplicated-firewall-ufw-is-not-blocking-anything-when-using-docker
• https://my.oschina.net/abcfy2/blog/539485
• https://www.v2ex.com/amp/t/466666
• https://blog.36web.rocks/2016/07/08/docker-behind-ufw.html
• …

基本上可以找到的解决办法就是首先禁用 docker 的 iptables 功能，但这也意味着放弃了 docker 的网络管理功能，很典型的现象就是容器将无法访问外部网络。在有的文章中也提到了可以在 UFW 的配置文件中手工添加一条规则，比如 -A POSTROUTING ! -o docker0 -s 172.17.0.0/16 -j MASQUERADE。但这也只是允许了 172.17.0.0/16 这个网络。如果有了新增的网络，我们也必须手工再为新增的网络添加这样类似的 iptables 规则。

期望的目标

目前网络上的解决方案都非常类似，而且也不优雅，我希望一个新的解决方案可以：

1. 不要禁用 Docker 的 iptables，像往常一样由 Docker 来管理自己的网络。这样有任何新增的 Docker 网络时都无需手工维护 iptables 规则，也避免了在 Docker 中禁用 iptables 之后可能带来的副作用。
2. 公共网络不可以访问 Docker 发布出来的端口，即使是使用类似 -p 0.0.0.0:8080:80 的选项把端口发布在所有的 IP 地址上。容器之间、内部网络之间都可以正常互相访问，只有公共网络不可以访问。 虽然可以让 Docker 把容器的某一个端口映射到服务器的私有 IP 地址上，这样公共网络上将不会访问到这个端口。但是这个服务器可能有多个私有 IP 地址，这些私有 IP 地址可能也会发生变化。
3. 可以很方便的允许公共网络直接访问某个容器的端口，而无需额外的软件和配置。就像是用 ufw allow 8080 这样允许外部访问 8080 端口，然后用 ufw delete allow 8080 就不再允许外部访问。

如何做？

撤销原先的修改

如果已经按照目前网络上搜索到解决方案修改过了，请先修改回来，包括：

1. 启用 Docker 的 iptables 功能，删除所有类似 --iptables=false 的修改，包括 /etc/docker/daemon.json 配置文件。
2. UFW 的默认 FORWARD 规则改回默认的 DROP，而非 ACCEPT。
3. 删除 UFW 配置文件 /etc/ufw/after.rules 中与 Docker 网络相关的规则。
4. 如果修改了 Docker 相关的配置文件，重启 Docker。稍后还要修改 UFW 的配置，可以一并重启。

解决 UFW 和 Docker 的问题

目前新的解决方案只需要修改一个 UFW 配置文件即可，Docker 的所有配置和选项都保持默认。

修改 UFW 的配置文件 /etc/ufw/after.rules，在最后添加上如下规则：

# BEGIN UFW AND DOCKER
*filter
:ufw-user-forward - [0:0]
:DOCKER-USER - [0:0]
-A DOCKER-USER -j RETURN -s 10.0.0.0/8
-A DOCKER-USER -j RETURN -s 172.16.0.0/12
-A DOCKER-USER -j RETURN -s 192.168.0.0/16

-A DOCKER-USER -j ufw-user-forward

-A DOCKER-USER -j DROP -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -d 192.168.0.0/16
-A DOCKER-USER -j DROP -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -d 10.0.0.0/8
-A DOCKER-USER -j DROP -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -d 172.16.0.0/12
-A DOCKER-USER -j DROP -p udp -m udp --dport 0:32767 -d 192.168.0.0/16
-A DOCKER-USER -j DROP -p udp -m udp --dport 0:32767 -d 10.0.0.0/8
-A DOCKER-USER -j DROP -p udp -m udp --dport 0:32767 -d 172.16.0.0/12

-A DOCKER-USER -j RETURN
COMMIT
# END UFW AND DOCKER

然后重启 UFW，sudo systemctl restart ufw。现在外部就已经无法访问 Docker 发布出来的任何端口了，但是容器内部以及私有网络地址上可以正常互相访问，而且容器也可以正常访问外部的网络。可能由于某些未知原因，重启 UFW 之后规则也无法生效，请重启服务器。

如果希望允许外部网络访问 Docker 容器提供的服务，比如有一个容器的服务端口是 80。那就可以用以下命令来允许外部网络访问这个服务：

ufw route allow proto tcp from any to any port 80

这个命令会允许外部网络访问所有用 Docker 发布出来的并且内部服务端口为 80 的所有服务。

请注意，这个端口 80 是容器的端口，而非使用 -p 0.0.0.0:8080:80 选项发布在服务器上的 8080 端口。

如果有多个容器的服务端口为 80，但只希望外部网络访问某个特定的容器。比如该容器的私有地址为 172.17.0.2，就用类似下面的命令：

ufw route allow proto tcp from any to 172.17.0.2 port 80

如果一个容器的服务是 UDP 协议，假如是 DNS 服务，可以用下面的命令来允许外部网络访问所有发布出来的 DNS 服务：

ufw route allow proto udp from any to any port 53

同样的，如果只针对一个特定的容器，比如 IP 地址为 172.17.0.2：

ufw route allow proto udp from any to 172.17.0.2 port 53

解释

在新增的这段规则中，下面这段规则是为了让私有网络地址可以互相访问。通常情况下，私有网络是比公共网络更信任的。

-A DOCKER-USER -j RETURN -s 10.0.0.0/8
-A DOCKER-USER -j RETURN -s 172.16.0.0/12
-A DOCKER-USER -j RETURN -s 192.168.0.0/16

下面的规则是为了可以用 UFW 来管理外部网络是否允许访问 Docker 容器提供的服务，这样我们就可以在一个地方来管理防火墙的规则了。

-A DOCKER-USER -j ufw-user-forward

下面的规则阻止了所有外部网络发起的连接请求，但是允许内部网络访问外部网络。对于 TCP 协议，是阻止了从外部网络主动建立 TCP 连接。对于 UDP，是阻止了所有小余端口 32767 的访问。为什么是这个端口的？由于 UDP 协议是无状态的，无法像 TCP 那样阻止发起建立连接请求的握手信号。在 GNU/Linux 上查看文件 /proc/sys/net/ipv4/ip_local_port_range 可以看到发出 TCP/UDP 数据后，本地源端口的范围，默认为 32768 60999。当从一个运行的容器对外访问一个 UDP 协议的服务时，本地端口将会从这个端口范围里面随机选择一个，服务器将会把数据返回到这个随机端口上。所以，我们可以假定所有容器内部的 UDP 协议的监听端口都小余 32768，不允许外部网络主动连接小余 32768 的 UDP 端口。

-A DOCKER-USER -j DROP -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -d 192.168.0.0/16
-A DOCKER-USER -j DROP -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -d 10.0.0.0/8
-A DOCKER-USER -j DROP -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -d 172.16.0.0/12
-A DOCKER-USER -j DROP -p udp -m udp --dport 0:32767 -d 192.168.0.0/16
-A DOCKER-USER -j DROP -p udp -m udp --dport 0:32767 -d 10.0.0.0/8
-A DOCKER-USER -j DROP -p udp -m udp --dport 0:32767 -d 172.16.0.0/12

-A DOCKER-USER -j RETURN

一个典型的 Shell 脚本的详细讲解和重构

上周无意中看到了一个 Shell 脚本，是一个很典型的开发工程师思维的脚本。我将会先分步讲解一下这个看上去很简单的脚本，随后再看如何重构。

脚本的完整代码如下：

PACKAGE="\"$1\""

line=$(java -version 2>&1  | grep $PACKAGE | grep -iv openjdk | wc -l)
#echo $line

if [[ $line =~ 0 ]]; then
  echo '{ "found": false , "not_found": true  }'

else
  echo '{ "found": true  , "not_found": false }'

fi

TL;DR 警告：如果太长不想看，就翻到最后看重构结果。

脚本的详细讲解

这段脚本的需求就是判断是否已经安装了特定版本的 Oracle JDK。在调用的时候会传入 Java 的版本号码，比如：1.8.0_161，这就是 $1 的值。

首先定义了 PACKAGE 这个变量，为什么在把 $1 赋值给 PACKAGE 的时候要转义双引号呢？是因为 java -version 这个命令输出的时候，版本号码是有双引号的。所以定义这个 PACKAGE 的作用是要精准匹配 java 的版本。

# Oracle JDK
chaifeng@local ~ $ java -version
java version "1.8.0_161"
Java(TM) SE Runtime Environment (build 1.8.0_161-b12)
Java HotSpot(TM) 64-Bit Server VM (build 25.161-b12, mixed mode)

# OpenJDK
chaifeng@local ~ $ java -version
openjdk version "1.8.0_144"
OpenJDK Runtime Environment (Zulu 8.23.0.3-macosx) (build 1.8.0_144-b01)
OpenJDK 64-Bit Server VM (Zulu 8.23.0.3-macosx) (build 25.144-b01, mixed mode)

然后就开始执行判断，并把结果赋值给变量 line。这行脚本看上去做了很多的事情，我们来拆开看一下。

java -version 用来输出版本号，但是输出到了标准错误上。而默认情况下，标准错误是无法通过管道传递给下一个命令的。所以需要 2>&1 来把标准错误的内容重定向到标准输出，这样才可以把 java 的版本号码传递给 grep 命令，否则 grep 是无论如何都无法获取到 java -version 的输出的。

第一个 grep 命令用来过滤 java -version 输出中包含版本号的所有行，并且这个版本号是用双引号包含起来的。正常情况下将会得到 java -version 命令输出的第一行。

然后再把结果传递给 grep -iv openjdk 命令。grep 的 -i 选项是匹配时忽略大小写。-v 选项是排除，也就是反向匹配，将会输出不匹配的所有行。如果系统中正在使用的是 OpenJDK，前一个 grep 命令只是判断是否是指定版本的 JDK，包括 Oracle JDK 和 OpenJDK。这个 grep 命令将排除 OpenJDK 的输出，所以如果当前系统中使用的是 OpenJDK，这个命令执行之后可能会得到空的结果。

最后再用 wc -l 命令来得到结果的行数。如果是特定版本的 Oracle JDK，那结果就是一行。如果不是特定版本的 Oracle JDK，或者是 OpenJDK，就会输出空的结果，所以行数将会是 0。

line 这个变量就会保存最后结果的行数，如果是 0 行显然就是系统中没有使用特定版本的 Oracle JDK。所以这里用了 [[ $line =~ 0 ]] 来判断变量 line 是否为 0。

为什么最后会根据 line 是否为 0 来输出一个 JSON 的字符串呢？是因为这个脚本将在 Ansible Playbook 中调用。相关的 Ansible 代码如下：

- name: copy scripts to server
  copy: src="../files/check-java-version.sh"  dest="{{ java_download_path }}/"  mode="a+x"

- name: check if specific version of Oracle JDK is installed?
  shell: LC_ALL="en_US.UTF-8"  {{ java_download_path }}/check-java-version.sh  "{{ jdk_version }}"
  register: jdk_info
  changed_when: false
  failed_when: jdk_info.rc > 0

#- debug: var=jdk_info

- include: install.yml
  when: (jdk_info.stdout|from_json).not_found

这里有3个 task。第一个 task 是把脚本复制到服务器上，并设置了执行权限。第二个 task 是执行这个脚本，并且传入了 java 的版本，最后把 task 的执行结果保存到 Ansible 变量 jdk_info 中。jdk_info 的 stdout 就将是 Shell 脚本最后输出的那个 JSON 字符串，比如：{ "found": false , "not_found": true }。第三个 task 是把第二个 task 的执行结果转换为 JSON 对象，并判断这个对象中的 not_found 的值是否为 true 来决定是否加载 install.yml 这个文件。

开始重构

所有相关的代码都分析完了，我们来看看如何重构，以及里面有哪些需要注意的问题。

之前也给几位朋友看过这个脚本，大部分人觉得问题主要在最后的 if 那里，尤其是输出 JSON 字符串的时候有互为相反的 found 和 not_found 两个值。

先说典型问题，首先就是在 Bash 脚本中，如果不是特别需要，所有的变量一定要加上双引号！有没有双引号在 Bash 中是不一样的，不仅仅是双引号里面变量会被替换，而单引号不替换这个区别。

其次 if 的条件判断用了 =~ 这个操作符，这是 Bash 中的正则匹配的判断。判断语句 [[ $line =~ 0 ]] 的含义是判断变量 line 这个字符串里面是否包含字符 0。所以当 line 的值为 10, 201 都可以成功匹配的，这里显然不是期望这么判断的。当然了，正常情况下，line 的值要么是 1 要么是 0。正确的做法是，这里应该用 -eq 操作符来判断 line 这个变量是否等于数值 0。

[[ "$line" -eq 0 ]]

最后是这个 if 判断有没有必要呢？

通常我们在 Java、Python、C 等语言里面函数的执行结果就是其返回值。在 Shell 脚本中，每一个命令的执行结果就是其输出。所以，对于刚从开发转到运维的工程师来说，就会习惯的想到根据命令的输出结果来判断。但 Shell 中还有一个很常用的判断方法就是根据命令的退出状态。如果命令执行成功，那退出状态就是 0，否则就是非 0。根据退出状态的不同，我们还可以知道命令为什么会执行失败。在 Bash 中，内部变量 $? 保存的就是前一个命令的退出状态。其实 Shell 脚本里的退出状态也可以类比为其他编程语言中的抛出异常。

Shell 脚本的退出状态就是脚本里面执行的最后一个命令的退出状态。通常我们不在意命令的输出，而只要根据退出状态来判断执行结果就可以了。对于现在重构的这个检查 Java 版本的脚本也一样，如果退出状态是 0 说明系统中是特定版本的 Oracle JDK。如果退出状态为非 0 说明不是特定版本的 Oracle JDK 或者安装的是 OpenJDK。

如果用退出状态来判断 Java 版本，那就没有必要输出 JSON 格式的结果了。if 的那5行代码就可以换成一行：

[[ "$line" -eq 1 ]]

如果是特定版本的 Oracle JDK，那变量 line 的值就是 1，这个判断就会成功，Shell 的退出状态就将是 0，否则是 1。

可不可以再简单一点儿呢？是的，返回结果的行数也是没必要的。在获取行数那行里面

line=$(java -version 2>&1  | grep $PACKAGE | grep -iv openjdk | wc -l)

其实 java -version 2>&1 | grep $PACKAGE | grep -iv openjdk 就已经完成了特定 Oracle JDK 的判断。只有当前就是特定版本的 Oracle JDK 的时候，这个管道命令的退出状态才是 0，否则就是 1。那这个脚本就可以改写为 1 行：

java -version 2>&1  | grep "\"$1\"" | grep -iv openjdk

既然我们改用退出状态来判断结果了，那 Ansible 的 3 个 task 也要修改一下。由于脚本已经被改写为 1 行，其实也没必要放到一个脚本中专门执行了，所以就可以把第一个 task 删除掉。

第 2 个 task，原先是：

- name: check if specific version of Oracle JDK is installed?
  shell: LC_ALL="en_US.UTF-8"  {{ java_download_path }}/check-java-version.sh  "{{ jdk_version }}"
  register: jdk_info
  changed_when: false
  failed_when: jdk_info.rc > 0

最后有一行 failed_when: jdk_info.rc > 0，这行的含义就是如果命令执行失败就标记这个 task 为失败。类似于下面的代码：

if(jdk_info.rc == false)
  return false;
else
  return true;

所以其实这行本身就是没有用处的。但是现在我们要在 Ansible 中根据这个新的命令的退出状态来判断是否需要安装 Oracle JDK，所以需要忽略这个 task 的失败。因为 Ansible 在遇到任何 task 执行失败后都会终止执行剩余的 task。

改写后的 Ansible 代码如下：

- name: check if specific version of Oracle JDK is installed?
  shell: LC_ALL="en_US.UTF-8" java -version 2>&1 | grep  '"{{ jdk_version }}"' | grep -iv openjdk
  register: check_jdk
  changed_when: false
  ignore_errors: true

- include: install.yml
  when: ansible_check_mode or check_jdk is failed

最后用到了 Ansible 的内部变量 ansible_check_mode，用来判断是否运行在检查模式下。因为 Ansible 的 shell 模块不支持检查模式，所以当 Ansible 运行在检查模式下的时候，这个 task 会被忽略。导致 check_jdk 这个变量没有被定义，下一个 task 就会执行失败。

重构结果

删掉了一个脚本和一个 Ansible 的 task。

所以，原先脚本中的 java -version 2>&1 | grep $PACKAGE | grep -iv openjdk 这行就足够了，其它代码都不需要。Ansible 的 3 个相关 task 也可以删掉 1 个。

代码越多，Bug 也越多。

在我们老家，一些私人的重要纪念日还是按照农历日期的，比如生日什么的。如果是一些公共的假期，比如中秋、端午还好说，有很多现成的公共农历日历。如果是自己关心的几个农历日期就要自己添加提醒了，尤其是要批量添加20、30年的农历日历提醒，而且每年好几个。

为了省事，有两个事情需要解决：

• 获取特定农历日期对应的公历日期
• 在命令行下添加一个提醒到 Google Calendar 或者 Apple Calendar

用 lunar 来获取农历和公历的对应日期

编译

在 Debian 的仓库里面有一个名为 lunar 的软件可以查询农历和公历的对应日期。这个软件非常的老了，最新的版本是2001年10月发布的 2.2 版本。能够查询的日期范围是1900年到2049年之间的。在 macOS 上需要自己下载编译，目前无法从 Debian 的 git 仓库中获取源码，还好有打包好的 lunar 源码可以下载。

下载并解压后，执行 make 命令即可。虽然可以看到很多的警告信息，但在源码目录下已经编译成功。

基本用法

使用上非常简单，直接执行会看到简单的帮助信息。

注意到有一个选项 -h 是输出中文信息的，但由于这个软件太过于『古老』，以至于没有支持 UTF-8。所以如果你的终端的字符集不是 GBK 或者 GB18030，在使用 -h 选项的时候需要用 iconv 命令来把输出转换为当前终端的字符集。

lunar -h 2019 10 13 | iconv -f gb18030

有一个比较有趣的选项是 -b 可以以『位图』的方式输出

查询公历对应的农历日期

比如：要查询2019年10月13日对应的农历日期

lunar 2019 10 13

可以看到那天是农历的九月十五日。

用 -i 选项来查询农历对应的公历日期

比如：要查询2019年农历九月十五日对应的公历日期

lunar -i 2019 9 15

使用 Fantastical2 来添加日历

我购买了 Fantastical 2 for Mac，这是一个非常易用的 macOS 桌面日历工具。有一些比较强大的功能，比如：

• 支持自然语言来添加提醒
• 跨日历合并相同的提醒
• 支持 AppleScript
• ……

给一个特定的日期添加一个提醒

只要在 Fantastical 的输入框里面输入一行文字，带上日期即可。要指定一个地点，就在用『at』加上地址。如果有多个不同的日历来源，希望添加到特定的日历中，那就在行首加上『/日历名称』。

只有日期没有具体的时间时，默认是全天的事项。由于 Fantastical2 对中文的自然语言其实是没有什么支持了，所以精准的时间还是别用自然语言了。

比如我的默认日历是『工作』，希望添加到『家庭』的日历，就在最前面添加『/家庭』。

把添加事项自动化！

在 Fantastical2 的帮助文档的与其他应用整合里面有提到多种自动化的添加方式，比如用 URL 的方式：

open "x-fantastical2://parse?s=/家庭 2018-6-7 6:45 在太原机场打印行程单"

这会直接打开 Fantastical 的快速添加窗口，按下回车键即可添加一个事项。

这需要我们手工确认一下！自动化一定是 100% 的，没有 99% 的自动化。还有有个 add 选项，用上选项 add=1 就可以直接添加事项而无需确认了。

open "x-fantastical2://parse?s=/家庭 2018-6-7 6:45 在太原机场打印行程单&add=1"

执行这个命令后就直接在『家庭』日历中添加了一个事项。看上去不错了，但有个问题是，每次执行了命令 Fantastical 的窗口都会打开。毕竟 open 命令就是打开应用程序的。

自动化的实现中还是要避免本没有必要显示的窗口。

用 AppleScript 来实现完全的自动化

在 Fantastical 的帮助文档中可以看到一个 AppleScript 的例子

tell application "Fantastical 2" 
    parse sentence "Wake up at 8am" 
end tell

要实现完全的自动化，就加上 with add immediately

tell application "Fantastical 2" 
    parse sentence "Wake up at 8am" with add immediately 
end tell

现在我们已经知道了所有需要的信息了，创建一个 AppleScript 脚本 fantastical.scpt，内容如下：

on run argv
  set query to (item 1 of argv)
  tell application "Fantastical" to parse sentence query with add immediately
  return "添加日历：" & query
end run

然后就可以用 osascript 来执行这个脚本，并加上我们要添加的事项。

osascript fantastical.scpt "/家庭 2018-11-4 9am 去买个蛋糕"

执行这个命令时，Fantastical 的窗口也没有打开，完美。

写个 Shell 通过 lunar、Fantastical 来按照农历日期批量添加事项提醒

虽然我们已经搞定了几乎所有的事情，也只需要用 osascript 这个命令一行就可以自动的添加提醒事项，但是我们需要总是记得这个 fantastical.scpt 脚本在哪里。我希望直接就执行一个命令，不要再带上路径什么的。虽然有 PATH 这个环境变量，但只是对命令生效。如何可以直接执行 fantastical.scpt 而无需带上路径呢？

Shebang!

我们可以在网络上搜索到很多的 AppleScript 的代码，发现里面的注释都是用类似 SQL 的方式，是两个短线 --。但其实 AppleScript 从 Mac OS X Leopard 发布的 2.0 版本开始就支持用 # 来做注释了，所以 Shebang (Unix)！

在第一行添加上 #!/usr/bin/env osascript，并且给文件添加上可执行权限。

#!/usr/bin/env osascript

on run argv
  set query to (item 1 of argv)
  tell application "Fantastical" to parse sentence query with add immediately
  return "添加日历：" & query
end run

添加可执行权限

chmod +x fantastical.scpt

我习惯上把所有自己写的脚本都放到 $HOME/bin 这个目录中，并且这个目录也添加到了 PATH 环境变量里面。

把文件 fantastical.scpt 移动到 ~/bin 目录中，现在就可以直接执行啦！

mv fantastical.scpt ~/bin

fantastical.scpt "/家庭 2018-11-4 9:30 再去买一个蛋糕吧"

目前感觉已经不错了，可以无需确认的添加一个事项，而且 Fantastical 的窗口也不会打开，在执行命令的时候也不用指定路径了。

但还是有一点 小小的缺陷，就是 fantastical.scpt 其实只支持一个参数。就是说，在添加事项的时候，一定别忘记用引号，否则会出问题的。比如

fantastical.scpt 买个蛋糕 2018-11-4

其实真正传递给 Fantastical 的内容只有『买个蛋糕』，而没有后面的的日期。所以默认就是在当天添加了一个『买个蛋糕』的事项，这不是我们要的。

虽然记得加上引号不是什么问题，但我们还可以做的更好。

一个简单的解决办法就是用 AppleScript 把传递进来的 argv 数组用空格连接起来，而不是只是获取数组的第一个元素。但对于自动化的实现来说，还有一种常用的传递参数的方式，是通过管道来传递。这种方式用 AppleScript 麻烦了一些，用 Shell 就很容易了。

用 Shell 让自动化再完美一些

用 Shell 可以解决两个问题：

• 把所有的参数用空格连接起来，作为一个参数传递给 fantastical.scpt
• 可以把通过管道传递过来的数据，转换为调用 fantastical.scpt 的参数

把所有的参数打包作为一个参数

用 Shell 接受参数是很容易的，在脚本中使用 $1、$2、$3、…… 就可以获得第1、2、3、……个参数。说到这里，或许有人不知道如何获取第10个或者以上参数。难道不就是 $10 吗？还真的不是！

看下面的 Bash 脚本

#!/bin/bash

echo 第十个参数是 $10

就是直接输出第 10 个参数，如果执行命令

./test-parameter.sh 1 2 3 4 5 6 7 8 9 a b c d e f

是不是应该就是输出：第十个参数是 a？让我们执行一下看看效果。

结果竟然是『第十个参数是 10』！莫非是把 a 当做十六进制转换为十进制？其实在 Bash 中，第1-9个参数可以直接用 $ 加数字，但第10个及其以上，需要用花括号{}包含起来，所以正确的代码应该是：

#!/bin/bash

echo 第十个参数是 ${10}

再次执行

./test-parameter.sh 1 2 3 4 5 6 7 8 9 a b c d e f

就会看到正确的结果：第10个参数是 a。

回到我们要解决的问题上，如何用 Bash 把接受到的所有参数用『空格』连接起来传递给 fantastical.scpt 呢？

很多人会知道在 Bash 下可以用 $@ 来代表所有的参数！

#!/usr/bin/env bash

fantastical.scpt "$@" # it's wrong

这样其实是不对的！有两个解决办法，一是先把$@赋值给一个变量，然后把变量传递给 fantastical.scpt

#!/usr/bin/env bash

QUERY="$@"
fantastical.scpt "$QUERY"

另一个办法是用 $*

#!/usr/bin/env bash

fantastical.scpt "$*"

以上两种方式可以任选一个。在 Bash 里面 $@ 和 $* 是不一样的，这里就不细谈了。

把通过管道接受的数据传递过去

通过管道传递的数据是无法用 $@ 或者 $* 来获取的，但是可以用 cat 来获取，代码如下：

#!/usr/bin/env bash
set -eu

QUERY="$(cat)"
"${BASH_SOURCE}.scpt" "$QUERY"

现在有了新问题，如何判断当前是要通过管道接受数据呢？通常情况下，通过管道接受数据的时候是没有参数的，所以一个办法就是通过内置变量 $# 来判断是否有参数。但这个判断并不准确，有时候我们需要在代码中判断如果没有任何选项参数的时候就显示一个简单的帮助信息。还有一个常见的判断方法就是利用 tty 这个命令。tty 会显示当前终端的名字，如果是通过管道接受数据，则会出错，显示 not a tty 的错误信息。

利用 tty 来区分是否从管道获取数据，代码如下

#!/usr/bin/env bash
set -eu

if tty; then
  QUERY="$@"
else
  QUERY="$(cat)"
fi

fantastical.scpt "$QUERY"

最后再改进一点儿，从管道获取数据的时候允许合并命令行上额外的参数，并且不显示 tty 的任何输出。

注意：IO 重定向 >/dev/null 2>&1 和 2>&1 >/dev/null 这两个是不同的。

#!/usr/bin/env bash
set -eu

QUERY="$@"

if ! tty >/dev/null 2>&1; then
  QUERY="$QUERY $(cat)"
fi

fantastical.scpt "$QUERY"

最后如果发现没有任何信息要添加，也就是变量 QUERY 为空值，那就显示帮助信息，搞定！

完整的脚本

fantastical

#!/usr/bin/env bash
set -eu

QUERY="$@"

if ! tty >/dev/null 2>&1; then
  QUERY="$QUERY $(cat)"
fi

if [[ -z "$QUERY" ]]; then
  echo "Usage: "
  echo "  $0 /家庭 2019-10-13 8am 记得去买个蛋糕"
  exit 1
else
  "${BASH_SOURCE}.scpt" "$QUERY"
fi

fantastical.scpt

#!/usr/bin/env osascript

on run argv
  set query to (item 1 of argv)
  tell application "Fantastical" to parse sentence query with add immediately
  return "添加日历：" & query
end run

开始执行

比如我要给每年的农历九月十五这一天加一个提醒

for YEAR in {2018..2049}; do
  fantastical "$(lunar -i $YEAR 9 15 | grep -m1 -Eo "[0-9]{4}\.[0-9]{1,2}\.[0-9]{1,2}")" 这一天是农历的九月十五; 
done

就这么几行代码，搞定！写 Shell 脚本是不是很简单呢？

写完这两个脚本，并添加所有的农历日期提醒，也就半个来小时，写文章就多半天过去了。

TL;DR

请直接跳到最后看总结。

Dev 与 Ops 的技术栈对比

DevOps 是最近几年非常流行的词汇，有越来越多的公司开始实践 DevOps，但如何可以真正的把 DevOps 做好呢？

我曾经和几个业内朋友聊过，为什么现在的 DevOps 培训关注在协作或者工具上？这些就是把 DevOps 做好落地所需要的吗？那几个朋友也同意，只是关注在协作和工具上是不够的。

首先，运维（Ops）是一个全面并复杂的工作，并不是把开发团队开发完成的应用部署到生产环境，如果出了问题就找开发团队来解决。运维包括了系统、网络、数据库、安全、开发等不同领域的工作。要把运维这个工作做好也不止是会一些工具这么简单的事情。其次，也不只有 DevOps 才关注团队之间的协作。如果协作和工具对于做好 DevOps 是足够的，就好比协作和开发语言或者框架对于做好开发是足够的。但我们都知道，对于开发来说，除了协作、编程语言、开发框架外还有不少很重要的技能，而这些技能也是区分资深开发工程师和初级工程师的标准之一。作为一名资深的开发工程师，除了基本的编程语言和框架外，还需要了解和掌握一些高级知识。比如资深的 Java 开发工程师需要了解并掌握反射、类加载、垃圾回收、多线程开发、调试工具等等高级知识。这些高级知识可以帮助他们更好地处理一些疑难复杂问题，并构建更加健壮灵活的应用程序。而且也有越来越多的开发工程师开始意识到 TDD、重构这类工程实践可以帮助他们提升开发技能，以开发出代码质量更好，也易维护的应用。

对于 DevOps 来说，技术栈不仅仅包括开发和运维，还包括测试、安全、网络、业务等等领域，但开发和运维是相对重要的两个。对于提升开发质量的高级知识和技能，很多人都已经很熟悉了，但有哪些是做好运维的高级知识和技能呢？如果运维做不好，那也很难做好 DevOps 的落地实践。下面我们以 Java Web 开发工程师和 Unix/Linux 运维工程师为例，来做一个技术栈的对比。通过这个技术栈的对比，可以让我们更加清楚的看到做好运维的基础在哪里。

Java Web 开发技术栈

主要开发语言

对于 Java 开发工程师来说，哪个编程语言是主要开发语言呢？很显然是 Java。如果一个工程师的主要开发语言是 PHP，那他就是 PHP 开发工程师了。作为一名合格的 Java 开发工程师，显然要对 Java 语言非常熟悉。不需要对 Java 语言的每一个细节都了如指掌，但最起码对绝大多数的语法非常了解。很难想象一名对于 if 语句都不甚明了的 Java 开发工程师可以开发出高质量的 Java 应用。

还需要掌握其他编程语言或标记语言

Java 工程师在开发应用时只会用 Java 语言是不够的，还需要了解并掌握一些其他编程语言或标记语言。比如 SQL、JavaScript、CSS、HTML、XML 等等。如果使用了一些CSS框架，可能还要掌握 Less (层叠样式表) 或者 Sass。

核心开发库

在学习 Java 编程的时候，主要是在学习什么？事实上Java 语法并不多、也不复杂，在几天内就可以把所有的语法学习完毕。那在学习 Java 编程的时候是在学习什么呢？其实是在学习 Java Development Kit（JDK），这是 Java 开发的核心开发库。在 JDK 中有非常多的包和类，几乎没人可以记得有哪些包，每个包里面有哪些类。但作为一名合格的 Java 开发者，一定会熟悉一些常用包，比如： java.lang、 java.util、 java.io 等等。同样的，也很少有人可以记得这些常用的包里面有哪些类，但一定非常熟悉一些常用的类及其方法，比如：java.lang.String、java.io.File、java.util.HashMap 等等。

如果要开发嵌入式或者企业级 Java 应用，可能还要熟练掌握 Java ME 或者 Jakarta EE（以前的 Java EE、J2EE）。

除了 JDK 的核心类库以外，资深的 Java 工程师还要了解很多 Java 虚拟机的相关知识。比如Java 内存模型、垃圾回收、Java 的类加载、高效并发的 Java 多线程开发技术等等。

第三方类库

理论上，当一名 Java 开发工程师掌握了 Java 语法以及 JDK，并且也熟悉一些第三方的语言，他已经可以开发出几乎任何的 Java 应用程序了，虽然可能会花费比较多的精力和代价。我们可能会使用一些第三方的类库来避免『重新发明轮子』，比如 Apache Commons、Google Guava、SLF4J 等等。借助很多的第三方类库，Java 开发工程师可以非常方便的处理 Excel 文档、解码音频文件、校验 OpenPGP 签名、处理日志等等。这些第三方类库可能也依赖其他的类库，所以可能就需要 Apache Maven 或者 Gradle 来帮助进行依赖管理和构建。

框架

虽然有很多的第三方类库可以帮助 Java 开发工程师减少一些重复的代码开发工作，但是对于不同的项目可能会有一些类似的行为逻辑。比如对于绝大多数的 Web 项目，总是需要处理模板、数据与表单的绑定、异常的拦截和处理、权限和安全认证等等重复的工作，于是需要开发框架来简化这些重复的工作。开发框架与具体的应用和业务无关，但是实现了最为基本的软件架构和体系，并提供了通用的功能，以便让开发者关注在业务逻辑的实现上。所以，开发框架对于业务逻辑来说什么也没有做，开发工程师还是需要自己去实现所有的业务逻辑。常见的 Java 开发框架有 Spring Framework、Apache Struts 2、Play Framework 等。

框架固然重要，但编程语言的基础和核心开发库的掌握更重要。尽管有的公司内部有自己开发框架，并且内部的开发框架也实现了一些通用的业务逻辑。但对于每一个特定的内部项目来说，还是需要开发工程师去实现这些特定的业务逻辑代码。

以上已经列出了最为基本的 Java Web 开发技术栈，绝大部分的 Java Web 应用都是基于以上的技术栈来开发的。

基本的运行环境

对于 Java Web 应用，最基本的运行环境有 Apache Tomcat、Jetty 等。通常 Java 开发工程师会在开发环境、测试环境使用这些基本的运行环境来调试、测试应用程序。如果没有太多的用户，甚至也可以用到生产环境中。

一旦需要为更多的用户提供服务，单个的最基本的运行环境可能就不足以支撑了。

集群和高可用的运行环境

虽然也可以用 Tomcat 或者 Jetty 来搭建一个规模不大的集群环境，但是使用一些 Java 企业级应用服务器会让事情变的更简单，比如 IBM WebSphere、Oracle WebLogic Server、JBoss Enterprise Application Platform 等等。不仅有了更高的性能、更高可用性、增强的安全控制，也更方便的去管理和部署 Java 应用集群。

Java 的开发工作环境

作为一名 Java 开发工程师，平时的工作环境通常是在一个 Java 集成开发环境 中，可以是 IntelliJ IDEA、Eclipse 或者 NetBeans，甚至是使用 Vim 或者 Emacs 搭配一些 Java 开发相关的插件和命令行。不管是哪一个，至少一定会非常熟悉其中的一个。

资深的 Java 开发工程师可以在自己熟悉的开发环境中非常高效的工作，熟悉常用的配置、快捷键。通常通过观察一名 Java 开发工程师对于日常工作环境的熟练程度，基本上可以判断是否是一名经验丰富的开发工程师。

Unix/Linux 运维技术栈

主要的开发语言

Java 开发工程师的主要工作语言是 Java。那什么是 Unix/Linux 运维工程师的主要语言呢？有一些人会说是 Python，但其实应该是 Bash 或者其它某一个 Unix shell。对于这个结论，有些人可能会对此有些争议。现在我先简单的说明一下，首先 Bash 是一个 Shell，而 Python 不是。我们必须通过操作系统来使用计算机，但我们无法直接使用操作系统内核。Shell 是一个用户界面，用于访问操作系统内核所提供的服务，比如文件管理、进程管理等。其次 Bash 作为一个编程语言，绝大部分的人对 Bash 的语法了解比较有限。常见的一个误区是，认为 Bash 的语法比较奇怪。比如绝大部分编程语言的 if、while 等关键字后面是圆括号，而 Bash 用的是方括号 [ ]，并且这个方括号和表达式之间必须有个空格，而且如果没有空格就会出现语法错误。如果认为这是 Bash 奇怪语法的一部分，那就完全错误了。

请看下面的 5 个 Bash if 语句的例子，这些语句之间的区别就是 if 后面的『括号』，哪些语法是正确的？

1. if [ ... ]; then ...; fi
2. if [[ ... ]]; then ...; fi
3. if ( ... ); then ...; fi
4. if (( ... )); then ...; fi
5. if { ... }; then ...; fi

大部分人会认为第1、2个是正确的，毕竟经常在各种 Shell Script 里面见到，虽然不一定明白一个方括号和两个方括号的区别。少部分人猜测第3、4个或许也是正确的，多数也仅仅只是猜测而已。但几乎所有的人认为第5个是错误的，因为从来没有见过 if 关键字后面可以用『花括号』作为语法的编程语言。

其实，所有的5个语法都是正确的。如果答案不是这个，说明对 Bash 的语法并不熟悉，甚至不了解。很遗憾的是，甚至市面上的一些有关 Unix/Linux 运维的技术书籍里面也有这样的错误，有从国外翻译的也有国人编写的。

如果一名开发者在对于一个编程语言了解极为有限，甚至连语法都不熟悉的情况下，是如何得出这个语言『很简单』、『仅适合简单的任务，不适合做复杂的工作』、『语法怪异』、『没有某某编程语言强大』等结论的？

我猜这来源于一个根深蒂固的认知，认为脚本和代码不一样，脚本更简单，无需编译就可以执行。比如 Java 代码需要用 javac 命令编译后，才能用 java 命令来执行，不可以像 Bash 这样直接运行。

下面这个截图没有做过任何的修改，从截图上可以看到 Java 代码可以像 Bash 脚本一样直接执行！这怎么可能？但是在我的电脑上可以随时演示这个奇怪的『真正的 Java Script』例子，因为我用了 Zsh 的一些特性来实现了直接执行 Java 代码的功能。我只是通过这个例子来展示代码和脚本其实是同样的东西！ 脚本只是隐含了编译的过程，没有显式的编译并不意味着不需要编译，难道 CPU 可以直接执行脚本吗？别忘记在十多年前，我们不也把 Python，JavaScript 称作脚本语言吗？但现在都叫它们代码！

下面是我拍摄的几本书里面关于 Bash if 语法错误的例子：

这里就不继续讨论了，我会在另一篇文章里来单独聊一下 Bash。

还需要掌握其他编程语言或标记语言

仅仅会用 Shell 是不够的，合格的运维工程师也需要了解并掌握其他语言，比如：Python、Perl、SQL、XML 等等。也包括一些 sed、awk 这些命令也有自己的一套开发语言。

核心开发库

Java Development Kit（JDK）是 Java 开发的核心库，每一位合格的 Java 开发工程师都应该了解并掌握。那对于 Unix/Linux 运维工程师来说，运维工作的核心开发库是什么？

在学习 Java 的时候，我们花了绝大部分的时间在学习 JDK 上。那在学习 Shell 的时候，我们也不是一直在学习 Bash 的语法。虽然 Bash 的语法与其他编程语言有些不同，但也不多不复杂，只要花上几天也可以把所有语法了解完毕。那花了绝大部分的时间是在学习什么呢？是 Unix/Linux 的核心命令。

任何一个 Java 源码里面都会用到很多 JDK 里面的类库，同样，任何一个 Bash 脚本里面也会使用很多的 Unix/Linux 核心命令，比如 ls、cd、ps、grep、kill、cut、sort、uniq、wc、mkdir、rm、……。这些命令会随着 Unix/Linux 一起发布，随着系统一起更新。通常位于 /bin、/usr/bin、/sbin、/usr/sbin 等路径中。

与 Java 开发类似，几乎没有谁可以记得 JDK 的所有包和类。同样的，对于运维工程师来说也很少有谁可以记得所有的 Unix/Linux 的核心命令以及每个命令的所有选项。但是作为合格的运维工程师，需要非常熟悉并掌握一些常用的核心命令，以及这些命令常用的选项参数。

资深的 Java 工程师需要了解 JDK 和 Java 虚拟机的一些高级知识。对于资深的运维工程师来说，也一样需要了解 Unix/Linux 的一些高级知识，比如信号、进程、内存管理、磁盘管理、RAID、防火墙、路由表等等。所以如果一名运维工程师不明白 HUP 信号，而到处使用 nohup 命令启动程序，或者不分青红皂白的总是使用 kill -9 来杀掉进程，很难相信他会是一名资深或者合格的运维工程师。

第三方类库

理论上，当一名运维工程师掌握了 Shell、其他编程语言以及Unix/Linux 的核心命令，他已经可以做几乎所有的运维工作了，但是将会花费他很多的精力和代价。比如要在不同的服务器之间同步文件，是可以通过 Shell 以及系统的核心命令来完成这个工作，但使用类似 rsync 这样的第三方工具会节省很多的时间和精力。

Unix/Linux 运维的第三方库就是不属于操作系统核心命令的那些命令，比如 rsync、 curl、zip、unzip、unrar、tmux、Xvnc、……等等，这些命令通常位于 /usr/bin、/usr/local/bin 等路径中。这些第三方的工具可就非常的多了。

框架

Java 开发者有不少的 Java 开发框架可以使用，比如 Spring、Struts 什么的。那运维的框架有哪些呢？或者运维工作中有『框架』这样的工具吗？好像从来没有听说过。

让我们先看一下 Java 开发工程师使用的开发框架，这些框架提供了一些通用的功能，可以帮助我们去做一些重复的工作，但是与具体的业务无关。在运维工程师在工作中有哪些通用重复的工作呢？比如：在安装一个软件包之前，可能需要检查这个软件包是否已经安装；在启动一个服务之前，要检查这个服务是否已经启动；在修改用户密码之前，先检查用户的密码是不是就是当前就要修改的这个密码；在完成一系列的运维工作后，可能需要生成一份报表，在哪些服务器上做了哪些变更，哪些服务器出现了错误等等；……。

所以配置管理工具就好比运维工程师的开发框架，比如 Puppet、Chef、Ansible 等等。框架与具体的业务无关，运维工程师需要在服务器上安装什么软件包、需要做什么配置变更、该向哪个进程发送什么信号，不会因为使用了配置管理工具就可以不用去做。也或者，配置管理工具虽然可以帮助运维工程师重启某个特定的服务，但对于自定义的应用来说，重启时该做什么操作、需要监控哪个进程、应该切换到哪个用户的权限下，这些工作还是需要运维工程师自己去实现。

以上列出了最基本的 Unix/Linux 运维工程师的技术栈，绝大部分的 Unix/Linux 运行环境都是基于这个技术栈来维护管理的。

基本的运行环境

对于运维工程师来说，最基本的管理环境就是一台独立的服务器、虚拟机、VPS、或者一个 Docker 容器等等。通常开发环境或者测试环境都运行在一个比较基本的运行环境中，如果没有太多的用户，也可以用于生产环境。

一旦要为更多的用户提供服务，一台或者几台服务器可能就不够了，需要更多的服务器、VPS、Docker 容器。

集群和高可用的运行环境

如果运行节点很多，环境也比较复杂，可能就需要比如 Amazon AWS、OpenStack、Google云端平台 等平台帮我们管理大规模的 VPS 环境。对于 Docker 容器，可能就需要 Kubernetes、Docker Swarm 等平台。

借助这些 IaaS 平台，不仅有了更灵活的管理、更高的可用性和安全性。运维工程师可以非常方便的把应用部署到一个集群中，或者一个简单的命令就可以增加或减少服务节点数量，监控和维护整个应用集群。

运维的工作环境

Java IDE 是 Java 开发工程师的工作环境，运维工程师的工作环境呢？有人会说是 Vim，因为很多的运维工程师在服务器上都是用 Vim 来修改配置文件的。Java 工程师可以在一个 Java IDE 中去完成几乎所有的开发工作，运维工程师可以不用退出 Vim 而完成几乎所有的工作吗？（如果是使用 Emacs 还是有可能的，但 Vim 真的有点儿够呛。开个玩笑，不是要在这里引发编辑器之战，但的确也是事实！）

事实上，运维工程师的工作环境就是操作系统的 Shell，对于 Unix/Linux 来说就是命令行 或者 GNOME 这类的图形用户界面。

一名合格的运维工程师一定会非常熟悉他的工作环境的，如果一位 Windows 运维工程师不知道 Ctrl-x、Ctrl-v、Ctrl-z 等常用快捷键，很难相信他会是一位合格或者资深的 Windows 系统的运维工程师。有多少人知道可以在命令行进行剪切、粘贴、撤销等操作？

总结

通过这个对比，可以帮助我们看清楚一些问题。比如有人会问，已经在项目中使用了 Kubernates，还有必要使用 Ansible 吗？这就好比已经在项目中使用了 JBoss，还有必要使用 Spring Framework 吗？还有人会问，Unix/Linux 的各种命令实在太多了，学习使用 Chef 是不是可以容易点儿？这就好比学习 JDK 的各种类库太多了，学习 Play Framework 是不是可以让开发更容易些？

基础技能

从这个对比可以看出，表格的上半部分是基础技能，不管是对于 Java 开发工程师还是 Unix/Linux 运维工程师。

如果一个团队的开发质量比较差，系统 bug 多，对这个团队进行三天的 WebSphere 或者 Tomcat 培训可以起多大的作用？运维工作的质量不高，系统不稳定，三天的 Docker 或者 Kubernates 培训能改善多少？想想看，在三天的 Docker、Kubernates 培训中，花在 Dockerfile 的 RUN 指令后面的脚本上的时间有多少？花在与命令行与各种奇怪问题斗争的时间有多少？

有很多资深的开发工程师在写代码的时候总是会记得重构代码、要解耦、注意好的命名，但一写 Shell 脚本就全都忘记了。别忘记，脚本就是代码，代码有各种臭味，脚本也有。

一名优秀的运维工程师一定是优秀的开发工程师，但优秀的开发工程师不一定是优秀的运维工程师。

使用方法：
1、直接在 Alfred 里面粘贴 Zoom 的会议链接，按下回车就可以自动加入会议。如果 Zoom 还没有运行，也会自动运行起来。
2、 直接在 Alfred 里面粘贴 Zoom 的会议链接后，按下 Command 键会 新建一个会议，而不是加入现有的会议。并且会自动把新建的会议的 url 放入剪贴板，我们只要直接粘贴就可以。
3、有 `zm` 关键字，直接按下回车就是新建一个会议；
4、在 `zm` 关键字后面可以继续添加 meeting id，按下回车会自动加入；
5、在 `zm` 关键字后面无论是否有 meeting id，按下 Command 键都会新建一个会议。

源码：https://github.com/chaifeng/alfred-zoomus

下载：https://github.com/chaifeng/alfred-zoomus/releases

This Alfred Workflow is used to start or join a Zoom meeting.

Support free or paid account, you can join a meeting without logged in

Usage:

1. Paste a Zoom meeting URL in Alfred directly, press Enter, this will join an existing meeting.
2. Paste a Zoom meeting URL in Alfred, press Command + Enter, it will start a new meeting. And put the URL of this new meeting into your clipboard automatically.
3. A new keyword “zm” is used to start a new meeting.
4. Append an existing Zoom meeting ID after the keyword “zm”, it will join this meeting.
   for examples: zm 123-456-789, zm 123456789
5. Whether or not there is a meeting ID after keyword zm，press Command + Enter will always start a new meeting.

Source code: https://github.com/chaifeng/alfred-zoomus

Download: https://github.com/chaifeng/alfred-zoomus/releases

在当时，PC 给人的感觉是字符界面下的文字以及科学计算。虽然在 1995年的时候，Windows 95 已经发布。不过不要说播放视频了，就算听 MP3 都会卡顿。所以如果给一台 PC 添加了一个 CDROM、一个声霸卡以及用于解压电影的『硬解压卡』就可以让一台『普通』的 PC 做更多的多媒体的工作。于是就升级为『多媒体 PC』，也就是 MPC。在当时 MPC 还有级别之分，根据 CPU 的主频、内存、显卡支持的颜色数量等等指标来划分。

很快的，MPC 这个名字就淡出了我们的记忆。大概在1997、98年之后，已经很难看到这个名词了，因为那时的硬件性能遵循着摩尔定律在高速的发展中。已经无需添置硬解压卡就能看电影，CDROM 和声卡都已经成标配。现在对于一台 PC 可以做文字处理、科学计算、看电影、玩游戏、上网聊天就已经最为基本的功能了。PC 就是 PC！

从功能单一枯燥的 PC 和多媒体的 MPC，慢慢的，就只有了 PC。对于用户来说，在 PC 上可以编辑文字、播放音乐、修改图片、看电影、玩游戏是再普通不过的功能了。至于『MPC』是什么？1990年后出生的程序员们已经几乎没有谁知道了。

而在『MPC』的时代，会有『前端程序员』或者『后端程序员』吗？。在那时只有程序员，或者软件工程师。程序员要和客户沟通需求、写代码、做测试。当然也要自己搞定客户端和服务端。除了开发相关的工作外，还要做程序的安装、系统的配置和调优。知道如何启用 386 增强模式，如何使用高位内存。不要说配置防火墙和路由器了，连网线都会做。当时的网线可能都是同轴电缆，而且必须接上终结头，否则网络都不通。或许有人还记得『星型网络』或者『环形网络』。所以，以前的程序员真的是要会修电脑，而且很多程序员都以此为乐趣。甚至还有朋友会找程序员修电视，因为电脑也有个显示屏，和电视都很像。连电脑这么高科技的都会修，电视还能不会修？

在20世纪90年代后期，互联网开始迅速的发展起来。很快的，IT 就发展到我们的身边每一个角落了。软件的规模也越来越大，越来越复杂，程序员的职业开始细分。比如在2000年左右的时候，DBA 是一个非常热门的职业。如果你有了 DBA 的证书，你可以很容易的找到收入很高的工作。因为程序规模开始变大变复杂，独立的测试团队也开始出现。而且越来越多的公司开始需要网络工程师来负责和管理开始变得复杂的网络。运维团队也慢慢出现，负责软件的部署和维护。到了 2004 年，AJAX 技术是当年最重要的新技术之一。使用 AJAX，程序员可以开发出更加易用的 Web 前端，基于 AJAX 也出现了很多新的 Web 开发技术。如果一个程序员喜欢去做好的用户交互界面，就成为了前端工程师。还有一些程序员只喜欢和电脑打交道就成为了后端工程师。我们的开发团队就开始有前端程序员和后端程序员了。现在甚至有不同种类的前端工程师，React、AngulaJS、Android、iOS。

软件的规模越来越大、越来越复杂，但是程序员关注的范围却是越来越小。做前端的不懂后端，做后端的不了解前端。开发中的沟通成本和复杂就变得越来越高，随着互相的不了解，前端程序和后端程序在集成的时候就特别容易出现问题，很多软件的缺陷就因此而产生。如果一个程序员既了解前端也会做后端，是可以避免这种集成的问题的。为了减少因为沟通和理解造成的软件缺陷，『全栈工程师』就出现了，作为一名全栈工程师，不要求我们精通包括前端、后端、测试、运维等技术的方方面面，但一定要所有了解，一专多能，起码不会因此而出现沟通上的理解偏差。很多公司里面，全功能团队也在逐步的取代特性开发团队。

这个事情很有趣，以前会修电脑会做客户端服务端会网络会调优的程序员，慢慢的变成了，只会开发前端和后端或者会开发的不会运维的程序员。而那种什么也会做的就是『全栈工程师』。相信有越来越多的程序员希望成为『全栈工程师』，『全栈工程师』这个词也会消失。『全栈工程师』就像是20年前的『MPC』。