编写可靠Linux shell脚本的建议

编写可靠Linux shell脚本的八个建议https://yangxx.net/archives/949

1. 指定bash

shell 脚本的第一行，#!之后应该是什么？

如果拿这个问题去问别人，不同的人的回答可能各不相同。我见过/usr/bin/env bash，也见过/bin/bash，还有/usr/bin/bash，还有/bin/sh，还有/usr/bin/env sh。这算是编程界的“’茴’字四种写法”了。

在多数情况下，以上五种写法都是等价的。但是，写过程序的人都知道：“少数情况”里往往隐藏着意想不到的坑。

如果系统的默认 shell 不是 bash 怎么办？比如某 Linux 发行版的某个版本，默认的 sh 就不是 bash。

如果系统的 bash 不是在 /usr/bin/bash 怎么办？

我**推荐使用 /usr/bin/env bash 和 /bin/bash。**前者通过env添加一个中间层，让env在$PATH中搜索bash；后者则是官方背书的，约定俗成的 bash 位置，/usr/bin/bash不过是指向它的一个符号链接。

2. set -e 和 set -x

OK，经过一番讨论，现在第一行定下来了。接下来该开始写第二行了吧？
且慢！在你开始构思并写下具体的代码逻辑之前，先插入一行set -e和一行set -x。

set -x会在执行每一行 shell 脚本时，把执行的内容输出来。它可以让你看到当前执行的情况，里面涉及的变量也会被替换成实际的值。

set -e会在执行出错时结束程序，就像其他语言中的“抛出异常”一样。（准确说，不是所有出错的时候都会结束程序，见下面的注）

注：set -e结束程序的条件比较复杂，在man bash里面，足足用了一段话描述各种情景。大多数执行都会在出错时退出，除非 shell 命令位于以下情况：

一个 pipeline 的非结尾部分，比如 error | ok
一个组合语句的非结尾部分，比如 ok && error || other
一连串语句的非结尾部分，比如 error; ok
位于判断语句内，包括 test、if、 while 等等。
这两个组合在一起用，可以在 debug 的时候替你节省许多时间。出于防御性编程的考虑，有必要在写第一行具体的代码之前就插入它们。扪心自问，写代码的时候能够一次写对的次数有多少？大多数代码，在提交之前，通常都经历过反复调试修改的过程。与其在焦头烂额之际才引入这两个配置，不如一开始就给 debug 留下余地。在代码终于可以提交之后，再考虑是否保留它们也不迟。