编写Shell脚本的最佳实践,规范二
需要养成的习惯如下:
代码有注释 #!/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
编写Shell脚本的最佳实践,规范二的更多相关文章
- 编写Shell脚本的最佳实践
编写Shell脚本的最佳实践 http://kb.cnblogs.com/page/574767/ 需要记住的 代码有注释 #!/bin/bash # Written by steven # Name ...
- 编写Shell脚本的最佳实践,规范一
随着写的SHELL程序越来越多,发现自己每次写都有不同的习惯或者定义了不同的东西,变量名定义得不一样,整个程序缩进不统一,没有注释等问题,等我回过头看这些程序的时候发现很麻烦.所以写了个shell代码 ...
- 编写 Shell 脚本的最佳实践
转自:http://kb.cnblogs.com/page/574767/ 前言 由于工作需要,最近重新开始拾掇shell脚本.虽然绝大部分命令自己平时也经常使用,但是在写成脚本的时候总觉得写的很难看 ...
- Shell 脚本编程最佳实践
前言 由于工作需要,最近重新开始拾掇shell脚本.虽然绝大部分命令自己平时也经常使用,但是在写成脚本的时候总觉得写的很难看.而且当我在看其他人写的脚本的时候,总觉得难以阅读.毕竟shell脚本这个东 ...
- 编写shell脚本的规范
目录 编写shell脚本的一些规范 解释器 添加脚本版本和注释功能 添加脚本调试 变量命名 全局变量和局部变量 命名规范 函数命名 脚本命名 函数 引用模块或文件 脚本日志 配置文件 其他 编写she ...
- 编写shell脚本遇到的问题
运行shell脚本提示“syntax error near unexpected token for((i=0;i<$length;i++))”: 原因是因为Linux下的换行符是 \n 而你在 ...
- linux 的基本操作(编写shell 脚本)
终于到shell 脚本这章了,在以前笔者卖了好多关子说shell脚本怎么怎么重要,确实shell脚本在linux系统管理员的运维工作中非常非常重要.下面笔者就带你正式进入shell脚本的世界吧. 到现 ...
- 编写shell脚本实现对虚拟机cpu、内存、磁盘监控机制
一.安装Vmware,并通过镜像安装centos7. 二.安装xshell(可以不装,可以直接在虚拟机中直接进行以下步骤) 三.安装mail 一般Linux发送报警邮件通过本地邮箱或外部邮箱服务器,这 ...
- 在windows下编写shell脚本
注意两点: 1.第一行:#!/bin/bash 2.将文档格式转换为unix,因为在windows下编写shell脚本回车符是\n\r,而linux下的回车符是\n,所以在linux下运行脚本的时候, ...
随机推荐
- python系列4之装饰器
目录 递归算法解析 冒泡排序解析 装饰器解析 一. 递归 1. 递归的定义 递归(Recursion),又成为递回,在数学与计算机科学中,是指在函数的定义中使用函数自身的方法.递归一词还较长用于描述以 ...
- POJ:2431-Expedition
Expedition Time Limit: 1000MS Memory Limit: 65536K Total Submissions: 20089 Accepted: 5786 Descripti ...
- python向多个邮箱发邮件--注意接收是垃圾邮件
群发邮件注意:三处标红的地方 # -*- coding: UTF-8 -*- import smtplib from email.mime.text import MIMEText from emai ...
- wordCount的执行流程
我们对于wordCount的这个流程,在清晰不过了,不过我们在使用spark以及hadoop本身的mapReduce的时候,我们是否理解其中的原理呢,今天我们就来介绍一下wordCount的执行原理, ...
- 6.定制10MINS首页1
原始代码 <!DOCTYPE html> <html> <head> <meta charset="utf-8"> <titl ...
- \r \r\n \t的区别
\n 软回车: 在Windows 中表示换行且回到下一行的最开始位置.相当于Mac OS 里的 \r 的效果. 在Linux.unix 中只表示换行,但不会回到下一行的开始位置. ...
- (1)strchr
const char * strchr ( const char * str, int character ); char * strchr ( char * str, int character ) ...
- Eclipse 透视图(Perspective)---Eclipse教程第06课
什么是透视图? 透视图是一个包含一系列视图和内容编辑器的可视容器.默认的透视图叫 java. Eclipse 窗口可以打开多个透视图,但在同一时间只能有一个透视图处于激活状态. 用户可以在两个透视图之 ...
- 网易云深度剖析Kubernetes优化与实践
欢迎访问网易云社区,了解更多网易技术产品运营经验. 10 月 15 日,聚焦 Kubernetes 中国行业应用与技术落地的首届中国 Kubernetes 用户大会(KEUC)在杭州成功举办.本次大会 ...
- iOS笔记061 - 二维码的生成和扫描
二维码 生成二维码 二维码可以存放纯文本.名片或者URL 生成二维码的步骤: 导入CoreImage框架 通过滤镜CIFilter生成二维码 1.创建过滤器 2.恢复滤镜的默认属性 3.设置内容 4. ...