知道的都告诉你：编写 Shell 脚本的最佳实践！
Posted ITPUB技术小栈
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了知道的都告诉你：编写 Shell 脚本的最佳实践！相关的知识，希望对你有一定的参考价值。
前言
由于工作需要，最近重新开始拾掇 shell 脚本。虽然绝大部分命令自己平时也经常使用，但是在写成脚本的时候总觉得写的很难看。而且当我在看其他人写的脚本的时候，总觉得难以阅读。毕竟 shell 脚本这个东西不算是正经的编程语言，他更像是一个工具，用来杂糅不同的程序供我们调用。因此很多人在写的时候也是想到哪里写到哪里，基本上都像是一段超长的 main 函数，不忍直视。同时，由于历史原因，shell 有很多不同的版本，而且也有很多有相同功能的命令需要我们进行取舍，以至于代码的规范很难统一。
考虑到上面的这些原因，我查阅了一些相关的文档，发现这些问题其实很多人都考虑过，而且也形成了一些不错的文章，但是还是有点零散。因此我就在这里把这些文章稍微整理了一下，作为以后我自己写脚本的技术规范。
代码风格规范
开头有 “蛇棒”
所谓 shebang 其实就是在很多脚本的第一行出现的以”#!” 开头的注释，他指明了当我们没有指定解释器的时候默认的解释器，一般可能是下面这样：
#!/bin/bash
当然，解释器有很多种，除了 bash 之外，我们可以用下面的命令查看本机支持的解释器:
#/etc/shells: valid login shells
/bin/sh
/bin/dash
/bin/bash
/bin/rbash
/usr/bin/screen
当我们直接使用./a.sh来执行这个脚本的时候，如果没有 shebang，那么它就会默认用$SHELL指定的解释器，否则就会用 shebang 指定的解释器。
不过，上面这种写法可能不太具备适应性，一般我们会用下面的方式来指定：
#!/usr/bin/env bash
这种方式是我们推荐的使用方式。
代码有注释
注释，显然是一个常识，不过这里还是要再强调一下，这个在 shell 脚本里尤为重要。因为很多单行的 shell 命令不是那么浅显易懂，没有注释的话在维护起来会让人尤其的头大。
注释的意义不仅在于解释用途，而在于告诉我们注意事项，就像是一个 README。
具体的来说，对于 shell 脚本，注释一般包括下面几个部分：
shebang
脚本的参数
脚本的用途
脚本的注意事项
脚本的写作时间，作者，版权等
各个函数前的说明注释
一些较复杂的单行命令注释
参数要规范
这一点很重要，当我们的脚本需要接受参数的时候，我们一定要先判断参数是否合乎规范，并给出合适的回显，方便使用者了解参数的使用。
最少，最少，我们至少得判断下参数的个数吧：
if [[ $# != 2 ]];then
echo "Parameter incorrect."
exit 1
fi
变量和魔数
一般情况下我们会将一些重要的环境变量定义在开头，确保这些变量的存在。
source /etc/profile
export PATH=”/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin:/apps/bin/”
这种定义方式有一个很常见的用途，最典型的应用就是，当我们本地安装了很多 java 版本时，我们可能需要指定一个 java 来用。那么这时我们就会在脚本开头重新定义JAVA_HOME以及PATH变量来进行控制。
同时，一段好的代码通常是不会有很多硬编码在代码里的 “魔数” 的。如果一定要有，通常是用一个变量的形式定义在开头，然后调用的时候直接调用这个变量，这样方便日后的修改。
缩进有规矩
对于 shell 脚本，缩进是个大问题。因为很多需要缩进的地方 (比如 if,for 语句) 都不长，所有很多人都懒得去缩进，而且很多人不习惯用函数，导致缩进功能被弱化。
其实正确的缩进是很重要的，尤其是在写函数的时候，否则我们在阅读的时候很容易把函数体跟直接执行的命令搞混。
常见的缩进方法主要有”soft tab” 和”hard tab” 两种。
所谓 soft tab 就是使用 n 个空格进行缩进 (n 通常是 2 或 4)
所谓 hard tab 当然就是指真实的”\t” 字符
这里不去撕哪种方式最好，只能说各有各的优劣。反正我习惯用 hard tab。
对于 if 和 for 语句之类的，我们最好不要把 then，do 这些关键字单独写一行，这样看上去比较丑。。。
命名有标准
所谓命名规范，基本包含下面这几点：
文件名规范，以. sh 结尾，方便识别
变量名字要有含义，不要拼错
统一命名风格，写 shell 一般用小写字母加下划线
编码要统一
在写脚本的时候尽量使用 UTF-8 编码，能够支持中文等一些奇奇怪怪的字符。不过虽然能写中文，但是在写注释以及打 log 的时候还是尽量英文，毕竟很多机器还是没有直接支持中文的，打出来可能会有乱码。
权限记得加
这一点虽然很小，但是我个人却经常忘记，不加执行权限会导致无法直接执行，有点讨厌。。。
日志和回显
日志的重要性不必多说，能够方便我们回头纠错，在大型的项目里是非常重要的。
如果这个脚本是供用户直接在命令行使用的，那么我们最好还要能够在执行时实时回显执行过程，方便用户掌控。
有时候为了提高用户体验，我们会在回显中添加一些特效，比如颜色啊，闪烁啊之类的，具体可以参考 ANSI/VT100 Control sequences 这篇文章的介绍。
密码要移除
不要把密码硬编码在脚本里，不要把密码硬编码在脚本里，不要把密码硬编码在脚本里。
重要的事情说三遍，尤其是当脚本托管在类似 Github 这类平台中时。。。
太长要分行
在调用某些程序的时候，参数可能会很长，这时候为了保证较好的阅读体验，我们可以用反斜杠来分行：
./configure \
–prefix=/usr \
–sbin-path=/usr/sbin/nginx \
–conf-path=/etc/nginx/nginx.conf \
注意在反斜杠前有个空格。
编码细节规范
代码有效率
在使用命令的时候要了解命令的具体做法，尤其当数据处理量大的时候，要时刻考虑该命令是否会影响效率。
比如下面的两个 sed 命令：
sed -n '1p' file
sed -n '1p;1q' file
他们的作用一样，都是获取文件的第一行。但是第一条命令会读取整个文件，而第二条命令只读取第一行。当文件很大的时候，仅仅是这样一条命令不一样就会造成巨大的效率差异。
当然，这里只是为了举一个例子，这个例子真正正确的用法应该是使用head -n1 file命令。。。
勤用双引号
几乎所有的大佬都推荐在使用”$” 来获取变量的时候最好加上双引号。
不加上双引号在很多情况下都会造成很大的麻烦，为什么呢？举一个例子：
#!/bin/sh
#已知当前文件夹有一个a.sh的文件
var="*.sh"
echo $var
echo "$var"
他的运行结果如下：
a.sh
*.sh
为啥会这样呢？其实可以解释为它执行了下面的命令：
echo *.sh
echo "*.sh"
在很多情况下，在将变量作为参数的时候，一定要注意上面这一点，仔细体会其中的差异。上面只是一个非常小的例子，实际应用的时候由于这个细节导致的问题实在是太多了。。。
巧用 main 函数
我们知道，像 java，C 这样的编译型语言都会有一个函数入口，这种结构使得代码可读性很强，我们知道哪些直接执行，那些是函数。但是脚本不一样，脚本属于解释性语言，从第一行直接执行到最后一行，如果在这当中命令与函数糅杂在一起，那就非常难读了。
用 python 的朋友都知道，一个合乎标准的 python 脚本大体上至少是这样的：
#!/usr/bin/env python
def func1():
pass
def func2():
pass
if __name__=='__main__':
func1()
func2()
他用一个很巧妙的方法实现了我们习惯的 main 函数，使得代码可读性更强。
在 shell 中，我们也有类似的小技巧:
#!/usr/bin/env bash
func1(){
#do sth
}
func2(){
#do sth
}
main(){
func1
func2
}
main "$@"
我们可以采用这种写法，同样实现类似的 main 函数，使得脚本的结构化程度更好。
考虑作用域
shell 中默认的变量作用域都是全局的，比如下面的脚本：
#!/usr/bin/env bash
var=1
func(){
var=2
}
func
echo $var
他的输出结果就是 2 而不是 1，这样显然不符合我们的编码习惯，很容易造成一些问题。
因此，相比直接使用全局变量，我们最好使用local readonly这类的命令，其次我们可以使用declare来声明变量。这些方式都比使用全局方式定义要好。
巧用 heredocs
所谓 heredocs，也可以算是一种多行输入的方法，即在”<<” 后定一个标识符，接着我们可以输入多行内容，直到再次遇到标识符为止。
使用 heredocs，我们可以非常方便的生成一些模板文件：
cat>>/etc/rsyncd.conf << EOF
log file = /usr/local/logs/rsyncd.log
transfer logging = yes
log format = %t %a %m %f %b
syslog facility = local3
EOF
学会查路径
很多情况下，我们会先获取当前脚本的路径，然后一这个路径为基准，去找其他的路径。通常我们是直接用pwd以期获得脚本的路径。
不过其实这样是不严谨的，pwd获得的是当前 shell 的执行路径，而不是当前脚本的执行路径。
正确的做法应该是下面这两种：
script_dir=$(cd $(dirname $0) && pwd)
script_dir=$(dirname $(readlink -f $0 ))
应当先 cd 进当前脚本的目录然后再 pwd，或者直接读取当前脚本的所在路径。
代码要简短
这里的简短不单单是指代码长度，而是只用到的命令数。原则上我们应当做到，能一条命令解决的问题绝不用两条命令解决。这不仅牵涉到代码的可读性，而且也关乎代码的执行效率。
最最经典的例子如下：
cat /etc/passwd | grep root
grep root /etc/passwd
cat 命令最为人不齿的用法就是这样，用的没有任何意义，明明一条命令可以解决，他非得加根管道。。。
使用新写法
这里的新写法不是指有多厉害，而是指我们可能更希望使用较新引入的一些语法，更多是偏向代码风格的，比如
尽量使用func(){}来定义函数，而不是func{}
尽量使用[[]]来代替[]
尽量使用$()将命令的结果赋给变量，而不是反引号
在复杂的场景下尽量使用 printf 代替 echo 进行回显
事实上，这些新写法很多功能都比旧的写法要强大，用的时候就知道了。
其他小 tip
考虑到还有很多零碎的点，就不一一展开了，这里简单提一提。
路径尽量保持绝对路径，绝多路径不容易出错，如果非要用相对路径，最好用./ 修饰
优先使用 bash 的变量替换代替 awk sed，这样更加简短
简单的 if 尽量使用 && ||，写成单行。比如[[ x > 2]] && echo x
当 export 变量时，尽量加上子脚本的 namespace，保证变量不冲突
会使用 trap 捕获信号，并在接受到终止信号时执行一些收尾工作
使用 mktemp 生成临时文件或文件夹
利用 / dev/null 过滤不友好的输出信息
会利用命令的返回值判断命令的执行情况
使用文件前要判断文件是否存在，否则做好异常处理
不要处理 ls 后的数据 (比如ls -l | awk '{ print $8 }')，ls 的结果非常不确定，并且平台有关
读取文件时不要使用 for loop 而要使用 while read
与 100 + 技术大牛面对面
SACC2017
作为国内最受欢迎的架构师盛会，2017 第九届中国系统架构师大会 (SACC) 将于将于 2017 年 10 月 19-21 日在北京新云南皇冠假日酒店震撼来袭。
大会以 “云智未来” 为主题，云集国内外顶级专家，围绕云计算、人工智能、大数据、移动互联网、产业应用等热点领域展开技术探讨与交流。本届大会共设置 2 大主会场，18 个技术专场；邀请来自互联网、金融、制造业、电商等多个领域，100 余位技术专家及行业领袖来分享他们的经验；并将吸引 4000 + 人次的系统运维、架构师及 IT 决策人士参会，为他们提供最具价值的交流平台。
点击 “阅读原文” 与 100 + 技术大牛面对面，立享购票 7.8 折优惠~
以上是关于知道的都告诉你：编写 Shell 脚本的最佳实践！的主要内容，如果未能解决你的问题，请参考以下文章