LinuxShell脚本编程最佳实践

　　哈喽大家好!我是波哥!
　　最近做了一个简约版互联网行业新闻小程序.
　　有兴趣的可以点击下方链接或者微信搜索: IT路边社
　　IT路边社
　　前言
　　与其它的编码规范一样，这里所讨论的不仅仅是编码格式美不美观的问题， 同时也讨论一些约定及编码标准。这份文档主要侧重于我们所普遍遵循的规则，对于那些不是明确强制要求的，我们尽量避免提供意见。
　　为什么要有编码规范
　　编码规范对于程序员而言尤为重要，有以下几个原因：
　　一个软件的生命周期中，80%的花费在于维护
　　几乎没有任何一个软件，在其整个生命周期中，均由最初的开发人员来维护
　　编码规范可以改善软件的可读性，可以让程序员尽快而彻底地理解新的代码
　　如果你将源码作为产品发布，就需要确任它是否被很好的打包并且清晰无误，一如你已构建的其它任何产品
　　编码规范原则
　　本文档中的准则致力于最大限度达到以下原则：
　　正确性
　　可读性
　　可维护性
　　可调试性
　　一致性
　　美观
　　尽管本文档涵盖了许多基础知识，但应注意的是，没有编码规范可以为我们回答所有问题，开发人员始终需要再编写完代码后，对上述原则做出正确的判断。
　　代码规范等级定义
　　可选（Optional）：用户可参考，自行决定是否采用；
　　推荐（Preferable）：用户理应采用，但如有特殊情况，可以不采用；
　　必须（Mandatory）：用户必须采用（除非是少数非常特殊的情况，才能不采用）；
　　注：未明确指明的则默认为必须（Mandatory）
　　主要参考如下文档:
　　Google Shell Style Guide
　　Bash Hackers Wiki
　　源文件基础使用场景
　　仅建议Shell用作相对简单的实用工具或者包装脚本。因此单个shell脚本内容不宜太过复杂。
　　在选择何时使用shell脚本时时应遵循以下原则：
　　如主要用于调用其他工具且需处理的数据量较少，则shell是一个选择
　　如对性能十分敏感，则更推荐选择其他语言，而非shell
　　如需处理相对复杂的数据结构，则更推荐选择其他语言，而非shell
　　如脚本内容逐渐增长且有可能出现继续增长的趋势，请尽早使用其他语言重写
　　文件名
　　可执行文件不建议有扩展名，库文件必须使用.sh作为扩展名，且应是不可执行的。
　　执行一个程序时，无需知道其编写语言，且shell脚本并不要求具有扩展名，所以更倾向可执行文件没有扩展名。
　　而库文件知道其编写语言十分重要，使用.sh作为特定语言后缀的扩展名，可以和其他语言编写的库文件加以区分。
　　文件名要求全部小写, 可以包含下划线_或连字符-, 建议可执行文件使用连字符，库文件使用下划线。
　　正例:my-useful-binmy_useful_libraries.shmyusefullibraries.sh
　　反例：My_Useful_BinmyUsefulLibraries.sh
　　文件编码
　　源文件编码格式为UTF-8。避免不同操作系统对文件换行处理的方式不同，一律使用LF。
　　单行长度
　　每行最多不超过120个字符。每行代码最大长度限制的根本原因是过长的行会导致阅读障碍，使得缩进失效。
　　除了以下两种情况例外：
　　导入模块语句
　　注释中包含的URL
　　如出现长度必须超过120个字符的字符串，应尽量使用here document或者嵌入的换行符等合适的方法使其变短。
　　示例：# DO use ＂here document＂scat <echo ＂Process $: Done making $$$.＂
　　# 示例7：命令参数及路径不需要引号grep -li Hugo /dev/ ＂$1＂
　　# 示例8：常规变量用双引号，ccs可能为空的特殊情况可不用引号git send-email --to ＂${reviewers}＂ ${ccs:+＂--cc＂ ＂${ccs}＂}
　　# 示例9：正则用单引号，$1可能为空的特殊情况可不用引号grep -cP ＂([Ss]pecial||?characters*) ${1:+＂$1＂}
　　# 示例10：位置参数传递推荐带引号的＂$@＂，所有参数作为单字符串传递用带引号的＂$*＂# content of t.shfunc_t { echo num: $# echo args: 1:$1 2:$2 3:$3}
　　func_t ＂$@＂func_t ＂$*＂# 当执行 ./t.sh a b c 时输出如下：num: 3args: 1:a 2:b 3:cnum: 1args: 1:a b c 2: 3:

　　命令替换 　　使用 $(command)而不是反引号。 　　因反引号如果要嵌套则要求用反斜杠转义内部的反引号。而 $(command) 形式的嵌套无需转义，且可读性更高。 　　正例：var=＂$(command ＂$(command1)＂)＂ 　　反例：var=＂`command `command1``＂ 　　条件测试 　　使用 [[ ... ]]，而不是[,test, 和/usr/bin/[。 　　因为在 [[和]]之间不会出现路径扩展或单词切分，所以使用[[ ... ]]能够减少犯错。且[[ ... ]]支持正则表达式匹配，而[ ... ]不支持。参考以下示例：# 示例1：正则匹配，注意右侧没有引号# 详尽细节参考：http://tiswww.case.edu/php/chet/bash/FAQ 中E14部分if [[ ＂filename＂ =~ ^[[:alnum:]]+name ]]; then echo ＂Match＂fi 　　# 示例2：严格匹配字符串＂f*＂(本例为不匹配)if [[ ＂filename＂ == ＂f*＂ ]]; then echo ＂Match＂fi 　　# 示例3：中右侧不加引号将出现路径扩展，如果当前目录下有f开头的多个文件将报错[: too many argumentsif [ ＂filename＂ == f* ]; then echo ＂Match＂fi 　　字符串测试 　　尽可能使用变量引用，而非字符串过滤。 　　Bash可以很好的处理空字符串测试，请使用空/非空字符串测试方法，而不是过滤字符，让代码具有更高的可读性。正例：if [[ ＂${my_var}＂ = ＂some_string＂ ]]; then do_somethingfi 　　反例：if [[ ＂${my_var}X＂ = ＂some_stringX＂ ]]; then do_somethingfi 　　正例：# 使用-z测试字符串为空if [[ -z ＂${my_var}＂ ]]; then do_somethingfi 　　反例：# 使用空引号测试空字符串，能用但不推荐if [[ ＂${my_var}＂ = ＂＂ ]]; then do_somethingfi 　　正例：# 使用-n测试非空字符串if [[ -n ＂${my_var}＂ ]]; then do_somethingfi 　　反例：# 测试字符串非空，能用但不推荐if [[ ＂${my_var}＂ ]]; then do_somethingfi 　　文件名扩展 　　当进行文件名的通配符扩展时，请指定明确的路径。 　　当目录中有特殊文件名如以 -开头的文件时，使用带路径的扩展通配符./*比不带路径的*要安全很多。# 例如目录下有以下4个文件和子目录：# -f -r somedir somefile 　　# 未指定路径的通配符扩展会把-r和-f当作rm的参数，强制删除文件：psa@bilby$ rm -v *removed directory: `somedir＂removed `somefile＂ 　　# 而指定了路径的则不会:psa@bilby$ rm -v ./*removed `./-f＂removed `./-r＂rm: cannot remove `./somedir＂: Is a directoryremoved `./somefile＂ 　　慎用eval 　　应该避免使用eval。 　　Eval在用于分配变量时会修改输入内容，但设置变量的同时并不能检查这些变量是什么。反例：# 以下设置的内容及成功与否并不明确eval $(set_my_variables) 　　慎用管道连接 while 循环 　　请使用进程替换或者for循环，而不是通过管道连接while循环。 　　这是因为在管道之后的while循环中，命令是在一个子shell中运行的，因此对变量的修改是不能传递给父shell的。 　　这种管道连接while循环中的隐式子shell使得bug定位非常困难。反例：last_line=＂＂your_command | while read line; do last_line=＂${line}＂done 　　# 以下会输出＂＂：echo ＂${last_line}＂ 　　如果你确定输入中不包含空格或者其他特殊符号（通常不是来自用户输入），则可以用for循环代替。例如：total=0# 仅当返回结果中无空格等特殊符号时以下可正常执行：for value in $(command); do total+=＂${value}＂done 　　使用进程替换可实现重定向输出，但是请将命令放入显式子 shell，而非 while 循环创建的隐式子 shell。例如：total=0last_file=# 注意两个<之间有空格，第一个为重定向，第二个<为进程替换while read count filename; do total+=＂${count}＂ last_file=＂${filename}＂done < <(your_command | uniq -c) 　　echo ＂Total = ${total}＂echo ＂Last one = ${last_file}＂ 　　检查返回值 　　总是检查返回值，且提供有用的返回值。 　　对于非管道命令，使用 $? 或直接通过 if 语句来检查以保持其简洁。 　　例如：# 使用if语句判断执行结果if ! mv ＂${file_list}＂ ＂${dest_dir}/＂ ; then echo ＂Unable to move ${file_list} to ${dest_dir}＂ >&2 exit ＂${E_BAD_MOVE}＂fi 　　# 或者使用$?mv ＂${file_list}＂ ＂${dest_dir}/＂if [[ $? -ne 0 ]]; then echo ＂Unable to move ${file_list} to ${dest_dir}＂ >&2 exit ＂${E_BAD_MOVE}＂fi 　　内建命令和外部命令 　　当内建命令可以完成相同的任务时，在shell内建命令和调用外部命令之间，应尽量选择内建命令。 　　因内建命令相比外部命令而言会产生更少的依赖，且多数情况调用内建命令比调用外部命令可以获得更好的性能（通常外部命令会产生额外的进程开销）。 　　正例：# 使用内建的算术扩展addition=$((${X} + ${Y}))# 使用内建的字符串替换substitution=＂${string/#foo/bar}＂ 　　反例：# 调用外部命令进行简单的计算addition=＂$(expr ${X} + ${Y})＂# 调用外部命令进行简单的字符串替换substitution=＂$(echo ＂${string}＂ | sed -e ＂s/^foo/bar/＂)＂ 　　文件加载 　　加载外部库文件不建议用使用.，建议使用source，已提升可阅读性。正例：source my_libs.sh 　　反例：. my_libs.sh 　　内容过滤与统计 　　除非必要情况，尽量使用单个命令及其参数组合来完成一项任务，而非多个命令加上管道的不必要组合。常见的不建议的用法例如：cat和grep连用过滤字符串; cat和wc连用统计行数; grep和wc连用统计行数等。 　　正例：grep net.ipv4 /etc/sysctl.confgrep -c net.ipv4 /etc/sysctl.confwc -l /etc/sysctl.conf反例： 　　cat /etc/sysctl.conf | grep net.ipv4grep net.ipv4 /etc/sysctl.conf | wc -lcat /etc/sysctl.conf | wc -l 　　正确使用返回与退出 　　除特殊情况外，几乎所有函数都不应该使用exit直接退出脚本，而应该使用return进行返回，以便后续逻辑中可以对错误进行处理。正例：# 当函数返回后可以继续执行cleanupmy_func { [[ -e /dummy ]] || return 1} 　　cleanup { ...} 　　my_funccleanup 　　反例：# 当函数退出时，cleanup将不会被执行my_func { [[ -e /dummy ]] || exit 1} 　　cleanup { ...} 　　my_funccleanup 　　附：常用工具 　　推荐以下工具帮助我们进行代码的规范： 　　ShellCheck 　　原文链接：http://itxx00.github.io/blog/2020/01/03/shell-standards/ 　　获取更多的面试题、脚本等运维资料点击: 运维知识社区 获取 　　脚本之---短信轰炸机 　　脚本之---QQ微信轰炸机 　　ansible---一键搭建redis5.0.5集群 　　elk7.9真集群docker部署文档 　　全球最全loki部署及配置文档 　　最强安全加固脚本2.0 　　一键设置iptbales脚本

---