程序员必备神器!Shell 脚本编程最佳实践

做者:Myths
连接:https://blog.mythsman.com/201...

前言

因为工做须要,最近从新开始拾掇shell脚本。虽然绝大部分命令本身平时也常用,可是在写成脚本的时候总以为写的很难看。并且当我在看其余人写的脚本的时候,总以为难以阅读。毕竟shell脚本这个东西不算是正经的编程语言,他更像是一个工具,用来杂糅不一样的程序供咱们调用。java

所以不少人在写的时候也是想到哪里写到哪里,基本上都像是一段超长的main函数,不忍直视。同时,因为历史缘由,shell有不少不一样的版本,并且也有不少有相同功能的命令须要咱们进行取舍,以致于代码的规范很难统一。python

考虑到上面的这些缘由,我查阅了一些相关的文档,发现这些问题其实不少人都考虑过,并且  也造成了一些不错的文章,可是仍是有点零散。所以我就在这里把这些文章稍微整理了一下,做为之后我本身写脚本的技术规范。nginx

代码风格规范

开头有“蛇棒”git

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

#!/bin/bash

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

$ cat /etc/shells
#/etc/shells: valid login shells
/bin/sh
/bin/dash
/bin/bash
/bin/rbash
/usr/bin/screen

当咱们直接使用./a.sh来执行这个脚本的时候,若是没有shebang,那么它就会默认用$SHELL指定的解释器,不然就会用shebang指定的解释器。编程

这种方式是咱们推荐的使用方式。windows

代码有注释

注释,显然是一个常识,不过这里仍是要再强调一下,这个在shell脚本里尤其重要。由于不少单行的shell命令不是那么浅显易懂,没有注释的话在维护起来会让人尤为的头大。bash

注释的意义不只在于解释用途,而在于告诉咱们注意事项,就像是一个README。app

具体的来讲,对于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的时候仍是尽可能英文,毕竟不少机器仍是没有直接支持中文的,打出来可能会有乱码。这里还尤为须要注意一点,就是当咱们是在windows下用utf-8编码来写shell脚本的时候,必定要注意这个utf-8是不是有BOM的。默认状况下windows判断utf-8格式是经过在文件开头加上三个EF BB BF字节来判断的,可是在Linux中默认是无BOM的。所以若是咱们是在windows下写脚本的时候,必定要注意将编码改为Utf-8无BOM,通常用notepad++之类的编辑器都能改。不然,在Linux下运行的时候就会识别到开头的三个字符,从而报一些没法识别命令的错。固然,对于跨平台写脚本还有一个比较常见的问题就是换行符不一样。windows默认是\r\n而unix下是\n。不过有两个小工具能够很是方便的解决这个问题:dos2unix,unix2dos。

权限记得加

这一点虽然很小,可是我我的却常常忘记,不加执行权限会致使没法直接执行,有点讨厌。。。

日志和回显

日志的重要性没必要多说,可以方便咱们回头纠错,在大型的项目里是很是重要的。

若是这个脚本是供用户直接在命令行使用的,那么咱们最好还要可以在执行时实时回显执行过程,方便用户掌控。

有时候为了提升用户体验,咱们会在回显中添加一些特效,好比颜色啊,闪烁啊之类的,具体能够参考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来声明变量。这些方式都比使用全局方式定义要好。

函数返回值

在使用函数的时候必定要注意,shell中函数的返回值只能是整数,估计是由于通常状况下一个函数的返回值一般表示这个函数的运行状态,因此通常都是0或者是1就够了,所以就设计成了这样。不过,若是非得想传递字符串,也能够经过下面变通的方法:

func(){  
 echo "2333"  
}  
res=$(func)  
echo "This is from $res."

这样,经过echo或者print之类的就能够作到传一些额外参数的目的。

间接引用值

什么叫间接引用?好比下面这个场景:

VAR1="2323232"
VAR2="VAR1"

咱们有一个变量VAR1,又有一个变量VAR2,这个VAR2的值是VAR1的名字,那么咱们如今想经过VAR2来获取VAR1的值,这时候应该怎么办呢?

比较土鳖的方法是这样:

eval echo \$$VAR2

啥意思呢?其实就是构造了一个字符串echo XXX,这个XXX就是XXX”,这个XXX就是VAR2的值VAR1,而后再用eval强制解析,这样就作到了变相取值。

这个用法的确可行,可是看起来十分的不舒服,很难直观的去理解,咱们并不推荐。并且事实上咱们自己就不推荐使用eval这个命令。

比较舒服的写法是下面这样:

echo ${!VAR1}

经过在变量名前加一个!就能够作到简单的间接引用了。

不过须要注意的是,用上面的方法,咱们只可以作到取值,而不能作到赋值。若是想要作到赋值,还要老老实实的用eval来处理:

VAR1=VAR2
eval $VAR1=233
echo $VAR2
巧用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命令最为人不齿的用法就是这样,用的没有任何意义,明明一条命令能够解决,他非得加根管道。。。

其实代码简短在还能某种程度上能保证效率的提高,好比下面的例子:

#method1
find . -name '*.txt' |xargs sed -i s/233/666/g
find . -name '*.txt' |xargs sed -i s/235/626/g
find . -name '*.txt' |xargs sed -i s/333/616/g
find . -name '*.txt' |xargs sed -i s/233/664/g

#method1
find . -name '*.txt' |xargs sed -i "s/233/666/g;s/235/626/g;s/333/616/g;s/233/664/g"

这两种方法作的事情都同样,就是查找全部的.txt后缀的文件并作一系列替换。前者是屡次执行find,后者是执行一次find,可是增长了sed的模式串。第一种更直观一点,可是当替换的量变大的时候,第二种的速度就会比第一种快不少。这里效率提高的缘由,就是第二种只要执行一次命令,而第一种要执行屡次。而且,巧用xargs命令,咱们还能够十分方便的进行并行化处理:

find . -name '*.txt' |xargs -P $(nproc) sed -i "s/233/666/g;s/235/626/g;s/333/616/g;s/233/664/g"

经过-P参数指定并行度,能够进一步加快执行效率。

命令并行化

当咱们须要充分考虑执行效率时,咱们可能须要在执行命令的时候考虑并行化。shell中最简单的并行化是经过”&”以及”wait”命令来作:

func(){  
 #do sth  
}  
for((i=0;i<10;i++))do  
 func &  
done  
wait

固然,这里并行的次数不能太多,不然机器会卡死。稍微正确的作法比较复杂,之后再讨论,若是图省事可使用parallel命令来作,或者是用上面提到的xargs来处理。

全文本检索

咱们知道,当咱们想在文件夹下全部的txt文件中检索某一个字符串(好比233)的时候,咱们可能会用相似这样的命令:

find . -name '*.txt' -type f | xargs grep 2333

不少状况下,这个命令会想咱们所想的找到对应的匹配行,可是咱们须要注意两个小问题。

find命令会符合要求的匹配文件名,可是若是文件名包含空格,这时候将文件名传给grep的时候就会有问题,这个文件就会被当成两个参数,这时候就要加一层处理,保证用空格分开的文件名不会被当成两个参数:

find . -type f|xargs -i echo '"{}"'|xargs grep 2333

有时候,文件的字符集可能跟终端的字符集不一致,这时候就会致使grep在搜索时将文件当成二进制文件从而报binary file matches之类的问题。这时候要么用iconv之类的字符集转换工具将字符集进行切换,要么就在不影响查找的状况下对grep加-a参数,将全部文件当作文本文件:

find . -type f|xargs grep -a 2333

使用新写法

这里的新写法不是指有多厉害,而是指咱们可能更但愿使用较新引入的一些语法,更可能是偏向代码风格的,好比

尽可能使用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

使用cp -r命令复制文件夹的时候要注意若是目的文件夹不存在则会建立,若是存在则会复制到该文件的子文件夹下

静态检查工具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脚本写的溜,也是涨薪的必备技能哦!!若是本文对你有所帮助与借鉴,请点个在看转发分享支持一波哦!!

jishuroad.jpg

相关文章
相关标签/搜索