编写Shell脚本的最佳实践

编写Shell脚本的最佳实践

http://kb.cnblogs.com/page/574767/

 

 

须要记住的

代码有注释

#!/bin/bash
# Written by steven
# Name:        mysqldump.sh
# Version:      v1.0
# Parameters :   无
# Function:     mysqldump备份mysql
# Create Date:  2016-08-27


缩进有规矩

编码要统一 在写脚本的时候尽可能使用UTF-8编码


太长要分行

巧用heredocs


学会查路径
script_dir=$(cd $(dirname $0) && pwd)
script_dir=$(dirname $(readlink -f $0 )) 

使用新写法  printf代替echo

 

 

 

 

前言
因为工做须要，最近从新开始拾掇shell脚本。虽然绝大部分命令本身平时也常用，可是在写成脚本的时候总以为写的很难看。并且当我在看其余人写的脚本的时候，总以为难以阅读。毕竟shell脚本这个东西不算是正经的编程语言，他更像是一个工具，用来杂糅不一样的程序供咱们调用。所以不少人在写的时候也是想到哪里写到哪里，基本上都像是一段超长的main函数，不忍直视。同时，因为历史缘由，shell有不少不一样的版本，并且也有不少有相同功能的命令须要咱们进行取舍，以致于代码的规范很难统一。
考虑到上面的这些缘由，我查阅了一些相关的文档，发现这些问题其实不少人都考虑过，并且也造成了一些不错的文章，可是仍是有点零散。所以我就在这里把这些文章稍微整理了一下，做为之后我本身写脚本的技术规范。

 

代码风格规范


开头有“蛇棒”
所谓shebang其实就是在不少脚本的第一行出现的以”#!”开头的注释，他指明了当咱们没有指定解释器的时候默认的解释器，通常多是下面这样：

#!/bin/bash
固然，解释器有不少种，除了bash以外，咱们能够用下面的命令查看本机支持的解释器:

$ cat /etc/shells
#/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
脚本的参数
脚本的用途
脚本的注意事项
脚本的写做时间，做者，版权等
各个函数前的说明注释
一些较复杂的单行命令注释

 

 

备份mysql脚本   mysqldump  只备份表结构

#!/bin/bash
# Written by steven
# Name:        mysqldump.sh
# Version:      v1.0
# Parameters :   无
# Function:     mysqldump备份mysql
# Create Date:  2016-08-27

 

 

 

---

 

 

参数要规范

这一点很重要，当咱们的脚本须要接受参数的时候，咱们必定要先判断参数是否合乎规范，并给出合适的回显，方便使用者了解参数的使用。
最少，最少，咱们至少得判断下参数的个数吧：

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

---

静态检查工具shellcheck
概述

为了从制度上保证脚本的质量，咱们最简单的想法大概就是搞一个静态检查工具，经过引入工具来弥补开发者可能存在的知识盲点。
市面上对于shell的静态检查工具还真很少，找来找去就找到一个叫shellcheck的工具，开源在github上，有8K多的star，看上去仍是十分靠谱的。咱们能够去他的主页了解具体的安装和使用信息。
安装

这个工具的对不一样平台的支持力度都很大，他至少支持了Debian,Arch,Gentoo,EPEL,Fedora,OS X,openSUSE等等各类的平台的主流包管理工具。安装方便。具体能够参照安装文档
集成

既然是静态检查工具，就必定能够集成在CI框架里，shellcheck能够很是方便的集成在Travis CI中，供以shell脚本为主语言的项目进行静态检查。
样例

在文档的Gallery of bad code里，也提供了很是详细的“坏代码”的标准，具备很是不错的参考价值，能够在闲下来的时候当成”Java Puzzlers“之类的书来读读仍是很惬意的。
本质

不过，其实我以为这个项目最最精华的部分都不是上面的功能，而是他提供了一个很是很是强大的wiki。在这个wiki里，咱们能够找到这个工具全部判断的依据。在这里，每个检测到的问题均可以在wiki里找到对应的问题单号，他不只告诉咱们”这样写很差”，并且告诉咱们”为何这样写很差”，”咱们应当怎么写才好”，很是适合刨根问底党进一步研究。

 

　　

参考资料

关于 shell 脚本编程的10 个最佳实践
shell脚本编写规范
Shellcheck Tool
Best Practices for Writing Bash Scripts
Good coding practices for bash
Design patterns or best practices for shell scripts
bashstyle(GITHUB)
BashGuide/Practices
Obsolete and deprecated syntax
ANSI/VT100 Control sequences

 

 

 

 

f