让你的 shell 脚本变得可控

March 20, 2017

刚开始接触 shell 脚本的时候,最痛苦的地方在于出了问题,却不容易定位问题。

shell 脚本遇到错误,“大部分” 情况下都会继续执行剩下的命令,最后返回 Zero Exit Code 并不代表着结果正确。

这让人很难发现问题,它不像其他脚本语言,遇到 语法错误typo 等错误时便会立即退出。

如果想要写出容易维护、容易 debug 的 shell 脚本,我们就需要让 shell 脚本变得可控。

set -e

默认情况下,shell 脚本遇到错误并不会立即退出,它还是会继续执行剩下的命令。

[[email protected] ~]# cat example
#!/usr/bin/env bash
# set -e

sayhi # this command is not available.
echo "sayhi"
[[email protected] ~]# ./example
./example: line 4: sayhi: command not found
sayhi

我们知道 Linux/Unix 用户等于系统的时候,内核会加载 .bashrc 或者 .bash_profile 里的配置。

不同 shell 版本会使用不同的 rc/profile 文件,比如 zsh 版本的 rc 文件名是 .zshrc。

简单设想下,假如 shell 脚本遇到错误就退出,那么只要这些文件里有 typo 等错误,该用户就永远登陆不了系统。

在此,并没有考究默认行为的设计缘由,只是想表达 shell 脚本默认行为会让脚本变得不可控。

set -e 能会让 shell 脚本遇到 Non-Zero Exit Code 时,会立即停止执行。

[[email protected] ~]# cat example
#!/usr/bin/env bash
set -e

sayhi # this command is not available.
echo "sayhi"
[[email protected] ~]# ./example
./example: line 4: sayhi: command not found

set -u

初始化后再使用变量,这是好的编程习惯。

但在默认情况下,shell 脚本使用未初始化的变量并不会报错。

[[email protected] ~]# cat example
#!/usr/bin/env bash
# set -u

echo "Hi, ${1}"
[[email protected] ~]# ./example
Hi,
[[email protected] ~]# echo $?
0

若脚本设置 set -u ,一旦使用没有初始化的变量或者 positional parameter 时,脚本将立即返回 1 Exit Code。

[[email protected] ~]# cat example
#!/usr/bin/env bash
set -u

echo "Hi, ${1}"
[[email protected] ~]# ./example
./example: line 4: 1: unbound variable
[[email protected] ~]# echo $?
1

需要说明的是,对于预定义的 [email protected], $* 等这些变量,是可以正常使用。

为了避免使用未初始化的变量,常使用 ${VAR:-DEFAULT} 来设置默认值。

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

# ${VAR:-DEFAULT} evals to DEFAULT if VAR undefined.
foo=${nonexisting:-ping}

echo "${foo}" # => ping

bar="pong"

foo=${bar:-ping}

echo "${foo}" # => pong

# DEFAULT can be empty
empty=${nonexisting:-}

echo "${empty}" # => ''

set -o pipefail

在默认情况下,pipeline 会采用最后一个命令的 Exit Code 作为最终返回的 Exit Code。

[[email protected] ~]# cat example
#!/usr/bin/env bash
# set -o pipefail

grep string /non-existing-file | sort
[[email protected] ~]# ./example
grep: /non-existing-file: No such file or directory
[[email protected] ~]# echo $?
0

明明报错了,为什么还会返回 Zero Exit Code?

grep 一个并不存在的文件会返回 2 Exit Code。grep 不仅会输出错误信息到 STDERR 上,还会输出空的字符串到 STDOUT。对于 sort 命令而言,空字符串是合法的输入,所以最后命令返回 Zero Exit Code。

这样错误信息并不能很好地帮助我们改善脚本,返回的 Exit Code 应该要尽可能地反映错误现场。

和前面两个设置一样,set -o pipefail 会让 shell 脚本在 pipeline 过程遇到错误便立即返回相应错误的 Exit Code。

[[email protected] ~]# cat example
#!/usr/bin/env bash
set -o pipefail

grep string /non-existing-file | sort
[[email protected] ~]# ./example
grep: /non-existing-file: No such file or directory
[[email protected] ~]# echo $?
2

non-zero exit code is expected

这三个配置太过于苛刻,某些情况下还需要放宽这些限制:当程序可以接受 non-zero exit code 时。

这里有两种常用的方式去放宽限制:

set +

这里有一个脚本是用来产生长度为 64 的随机字符串:

[email protected] ~]# cat example
#!/usr/bin/env bash
set -euo pipefail

str=$(cat /dev/urandom | tr -dc '0-9A-Za-z' | head -c 64)

echo "${str}"

[[email protected] ~]# ./example
[[email protected] ~]# echo $?
141

该脚本有一个问题,就是 head 命令在获取到第 64 个字节之后,会关闭 STDIN,但是 pipe 还在不断地输出,导致内核不得不抛出 SIGPIPE 来终止命令。

因为设置 set -o pipefail 了 ,整个脚本因为 SIGPIPE 会退出。

假设该脚本剩下命令还很多,不能整体去掉 pipefail ,那么我们就局部放弃这个限制好了。

[[email protected] ~]# cat example
#!/usr/bin/env bash
# exit immediately if non-zero exit code/unset variable/pipe error
set -euo pipefail

# loosen up
set +o pipefail
str=$(cat /dev/urandom | tr -dc '0-9A-Za-z' | head -c 64)
set -o pipefail

echo "${str}"

[[email protected] ~]# ./example
pvScFHDZrdjlI091rQbruyEPM9e6iTN59IyzaKcCJwiCxYmiSNRmkFOfp0YuXi1C
[[email protected] ~]# echo $?
0

同理,只要设置上 set +e 或者 set +u 时,就会放宽相应的限制。

记得 有借有还,再借不难 就好了。

短路运算

现在有一个脚本,该脚本用来统计文件 file 中有多少行是包含了 string 这个字符串。

[email protected] ~]# cat example
#!/usr/bin/env bash
set -euo pipefail

count=$(grep -c string ./file)

echo "${count}"

[[email protected] ~]# ./example
[[email protected] ~]# echo $?
1
[[email protected] ~]# cat ./file
example

因为文件 file 中并不包含 string 这一字符串,所以 grep 返回 1 Exit Code。

假设遇到没有匹配上的文件,该脚本应该显示零,而不是错误。

$(cmd || true) 短路运算会让该命令永远都正常执行。

[[email protected] ~]# cat example
#!/usr/bin/env bash
set -euo pipefail

count=$(grep -c string ./file || true)

echo "${count}"

[[email protected] ~]# ./example
0
[[email protected] ~]# echo $?
0

思考

shell 脚本能帮助我们轻松地完成自动化的任务,这是它的优势。

但是劣势也比较明显,就是 shell 脚本的返回值。我们来看看下面的一个例子。

相对于 if/else, 短路运算可以让代码变得简洁。

但是一旦最终的判断结果为否,那么该短路运算将会返回 Non-Zero Exit Code。

假如有一个脚本的最后一条命令是短路运算。

[[email protected] ~]# cat ./echo_filename
#!/usr/bin/env bash
set -euo pipefail

file=${1:-}

[[ -f "${file}" ]] && echo "File: ${file}"
[[email protected] ~]# ./echo_filename
[[email protected] ~]# echo $?
1

如果没有传参数,那么短路运算将会返回 1 Exit Code,这个结果也将作为整个脚本的返回结果。

需要说明的是,虽然短路运算返回的 Non-Zero Exit Code,但 set -e 不会因为它而退出。

然后我们再看看使用 if/else 的结果。

[[email protected] ~]# cat echo_filename
#!/usr/bin/env bash
set -euo pipefail

file=${1:-}

if [[ -f "${file}" ]]; then
    echo "File: ${file}"
fi
[[email protected] ~]# ./echo_filename
[[email protected] ~]# echo $?
0

从逻辑上来分析,即使不传参数,呈现的应该是空字符串,并返回 Zero Exit Code。

if/else 语句相对于短路运算要合理。

我们别小看这一区别,如果这里有脚本调用 echo_filename,那么使用短路运算将会导致调用该脚本的脚本停止工作。

归根结底,是因为 shell 脚本并不像其他语言那样支持返回多种数据类型,它只能返回数字的 Exit Code。

这就代表着脚本的程序设计必须要考虑返回正确的 Exit Code,这样 set -euo pipefail 才能让脚本变得更加可控。

关于 set 更多的内容,请前往 Link