shell从入门到精通（32）优秀的shell编程习惯和规范

Posted 2022-12-21 奇妙之二进制

shell的使用场景

1、如果代码量较大（maybe超过100行或者更多），建议使用其他结构化的编程语言。

2、如果考虑性能，建议使用其他语言

开头有“蛇棒”

所谓shebang其实就是在很多脚本的第一行出现的以”#!”开头的注释，他指明了当我们没有指定解释器的时候默认的解释器，一般可能是下面这样：

#!/bin/bash

当然，解释器有很多种，除了bash之外，我们可以用下面的命令查看本机支持的解释器:

[root@thatsit 00:20:11 ~]# cat /etc/shells
/bin/sh
/bin/bash
/sbin/nologin
/bin/dash
/bin/tcsh
/bin/csh
/usr/bin/tmux
[root@thatsit 00:28:32 ~]#

当我们直接使用./a.sh来执行这个脚本的时候，如果没有shebang，那么它就会默认用$SHELL指定的解释器，否则就会用shebang指定的解释器。

不过，上面这种写法可能不太具备适应性，一般我们会用下面的方式来指定：

#!/usr/bin/env bash

代码有注释

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

具体的来说，对于shell脚本，注释一般包括下面几个部分：

写在文件头的注释：

1. 脚本的参数
2. 脚本的用途
3. 脚本的用法及注意事项
4. 脚本试用平台
5. 脚本的写作时间，作者，版权等

代码中的注释：

1. 各个函数前的说明注释（用途，参数含义，返回值意义）
2. 一些较复杂、不易理解、重要部分的注释

简单脚本头样例

#!/bin/bash
#########################################################
# Function :Rotate application logs                     #
# Platform :All Linux Based Platform                    #
# Version  :1.0                                         #
# Date     :2017-07-28                                  #
# Author   :Stephen.Shi                                 #
# Contact  :[e-mail]                                #
# Company  :MeiTu                                       #
#########################################################

参数要检查

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

• args judgement 姿势1

if [[ $# != 2 ]];then
    echo "Parameter incorrect."
    exit 1
fi

• args judgement 姿势2

# Uasge
echo_help()
    echo "Usage: $0 <server_group_to_operate>"


# arg judge
if [[ $# -ne 1 ]]
then
    echo_help
else
    func
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变量来进行控制。

同时，一段好的代码通常是不会有很多硬编码在代码里的“魔数”的。如果一定要有，通常是用一个变量的形式定义在开头，然后调用的时候直接调用这个变量，这样方便日后的修改。

变量的定义和引用

变量的定义和引用需要遵循一定的规范：

1. 名称长的变量尽量使用小写字母+下划线的方式进行命名，如home_dir
2. 常量的定义推荐使用大写字母+下划线进行命名，如HOME_DIR
3. 在引用变量时为了避免不必要的麻烦，尽量使用$变量名的方式进行引用

变量名引用的坑的样例

[root@thatsit scripts]$ cat var_test.sh
#!/bin/bash
xx="heiheihei"
xx_="123"
oo="666"
echo $xx$oo
echo "----"
echo $xx_$oo
echo "----"
echo $xx_$oo
[root@thatsit scripts]$ sh var_test.sh
heiheihei666
----
123666
----
heiheihei_666
[root@thatsit scripts]$

缩进有规矩

对于shell脚本，缩进是个大问题。因为很多需要缩进的地方(比如if,for语句)都不长，所有很多人都懒得去缩进，而且很多人不习惯用函数，导致缩进功能被弱化。
其实正确的缩进是很重要的，尤其是在写函数的时候，否则我们在阅读的时候很容易把函数体跟直接执行的命令搞混。
常见的缩进方法主要有”soft tab”和”hard tab”两种。

• 所谓soft tab就是使用n个空格进行缩进(n通常是2或4)
• 所谓hard tab当然就是指真实的”\\t”字符，这里不去撕哪种方式最好，只能说各有各的优劣。反正我习惯用四个空格。

命名有标准

所谓命名规范，基本包含下面这几点：

1. 文件名规范，以.sh结尾，方便识别
2. 通过脚本名称最好能够直接读出脚本的用途，所以好的命名就是动词+名词以描述干了一件什么事，比如常用xx服务的启动脚本可命名为start_xx.sh，oo服务的监控脚本可命名为monitor_oo.sh，告警脚本可名称为abc_alert.sh
3. 变量名字要有含义，不要拼错，尽量使用英文，可能显得更专业(ps:逼格高)一点，哈哈
4. 统一命名风格，用驼峰或者下划线连接，推荐使用小写字母加下划线的方式

编码要统一

在写脚本的时候尽量使用UTF-8编码，能够支持中文等一些奇奇怪怪的字符。
尽管脚本中可以写中文，但是在写注释以及打log的时候还是尽量英文，毕竟有些机器还是没有直接支持中文的，打出来可能会有乱码。

执行权限记得加

小点，却非常重要；不加执行权限经常会导致无法直接执行，尤其是init脚本等。

日志和回显

日志的重要性不必多说，能够方便我们回头纠错，在大型的项目里是非常重要的。
如果这个脚本是供用户直接在命令行使用的，那么我们最好还要能够在执行时实时回显执行过程，方便用户掌控。
有时候为了提高用户体验，可以回显中添加一些特效，比如颜色啊，闪烁啊之类的，具体可以参考ANSI/VT100 Control sequences这篇文章的介绍。

注意：

1. 一些debug级别的信息，在脚本调试结束后需要关闭。
2. 日志输出要带时间、要带时间、带时间，在写定时任务用的脚本时尤为重要。
3. 日志的输出推荐使用tee -a $log_file的方式，可以直接在main函数入口处添加日志输出。
4. 错误日志输出到STDERR

• 脚本日志输出样例

logfile="/var/log/log_clean.log"

# define functions
err() 
  echo "[$(date +'%Y-%m-%dT%H:%M:%S%z')]: $*" >&2


# define main function
function main()
    if ! do_something; then
      err "Unable to do_something"
      exit 1
    fi


# invoke main function
main|tee -a $logfile

太长要分行

在调用某些程序的时候，参数可能会很长，这时候为了保证较好的阅读体验，我们可以用反斜杠来分行（超过80个字符）：

./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 -1 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/bash

func1()
    #do sth


func2()
    #do sth


main()
    func1
    func2


main "$@"

我们可以采用这种写法，同样实现类似的main函数，使得脚本的结构化程度更好。

另外在传递参数的时候可能会遇到参数接收位置的变化，记得使用shift函数。

考虑作用域

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，或者直接读取当前脚本的所在路径；之前在编写nginx配置更新脚本的时候就遇到了这个操作姿势的坑。

代码要简短

这里的简短不单单是指代码长度，而是只用到的命令数。原则上我们应当做到，能一条命令解决的问题绝不用两条命令解决。这不仅牵涉到代码的可读性，而且也关乎代码的执行效率。
最最经典的例子如下：

cat /etc/passwd | grep root
grep root /etc/passwd

cat命令最为人不齿的用法就是这样，用的没有任何意义，明明一条命令可以解决，他非得加根管道；并且在处理大文件的时候第一种方式的效率会比较低。

尽量使用内置命令

# Prefer this:
addition=$(( X + Y ))
substitution="$string/#foo/bar"
# Instead of this:
addition="$(expr "$X" + "$Y")"
substitution="$(echo "$string" | sed -e 's/^foo/bar/')"

使用新写法

这里的新写法不是指有多厉害，而是指我们可能更希望使用较新引入的一些语法，更多是偏向代码风格的，比如

1. 尽量使用func()来定义函数，而不是func
2. 尽量使用[[]]来代替[]
3. 尽量使用$()将命令的结果赋给变量，而不是反引号
4. 在复杂的场景下尽量使用printf代替echo进行回显
5. 事实上，这些新写法很多功能都比旧的写法要强大，用的时候就知道了。

利用命令的返回值判断命令的执行情况

使用$? 变量或者if语句直接判断命令的执行结果：

if ! mv "$file_list[@]" "$dest_dir/"; then
  echo "Unable to move $file_list[*] to $dest_dir" >&2
  exit 1
fi

# Or
mv "$file_list[@]" "$dest_dir/"
if (( $? != 0 )); then
  echo "Unable to move $file_list[*] to $dest_dir" >&2
  exit 1
fi

PIPESTATUS数组可以获取管道命令的各个部分的返回值。

tar -cf - ./* | ( cd "$dir" && tar -xf - )
if (( PIPESTATUS[0] != 0 || PIPESTATUS[1] != 0 )); then
  echo "Unable to tar files to $dir" >&2
fi

需要注意的是[]也是命令，会覆盖PIPESTATUS的值。

其他小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