Linux编写可靠Linuxshell脚本的八个建议

编写可靠Linux shell脚本的八个建议

1. 指定bash
   shell 脚本的第一行&＃xff0c;#!之后应该是什么&＃xff1f;
   如果拿这个问题去问别人&＃xff0c;不同的人的回答可能各不相同。我见过/usr/bin/env bash&＃xff0c;也见过/bin/bash&＃xff0c;还有/usr/bin/bash&＃xff0c;还有/bin/sh&＃xff0c;还有/usr/bin/env sh。这算是编程界的“’茴’字四种写法”了。
   在多数情况下&＃xff0c;以上五种写法都是等价的。但是&＃xff0c;写过程序的人都知道&＃xff1a;“少数情况”里往往隐藏着意想不到的坑。
   如果系统的默认 shell 不是 bash 怎么办&＃xff1f;比如某 Linux 发行版的某个版本&＃xff0c;默认的 sh 就不是 bash。
   如果系统的 bash 不是在 /usr/bin/bash 怎么办&＃xff1f;
   我推荐使用 /usr/bin/env bash 和 /bin/bash。前者通过env添加一个中间层&＃xff0c;让env在$PATH中搜索bash&＃xff1b;后者则是官方背书的&＃xff0c;约定俗成的 bash 位置&＃xff0c;/usr/bin/bash不过是指向它的一个符号链接。

2. set -e 和 set -x
   OK&＃xff0c;经过一番讨论&＃xff0c;现在第一行定下来了。接下来该开始写第二行了吧&＃xff1f;
   且慢&＃xff01;在你开始构思并写下具体的代码逻辑之前&＃xff0c;先插入一行set -e和一行set -x。
   set -x会在执行每一行 shell 脚本时&＃xff0c;把执行的内容输出来。它可以让你看到当前执行的情况&＃xff0c;里面涉及的变量也会被替换成实际的值。
   set -e会在执行出错时结束程序&＃xff0c;就像其他语言中的“抛出异常”一样。&＃xff08;准确说&＃xff0c;不是所有出错的时候都会结束程序&＃xff0c;见下面的注&＃xff09;
   注&＃xff1a;set -e结束程序的条件比较复杂&＃xff0c;在man bash里面&＃xff0c;足足用了一段话描述各种情景。大多数执行都会在出错时退出&＃xff0c;除非 shell 命令位于以下情况&＃xff1a;
   一个 pipeline 的非结尾部分&＃xff0c;比如 error | ok
   一个组合语句的非结尾部分&＃xff0c;比如 ok && error || other
   一连串语句的非结尾部分&＃xff0c;比如 error; ok
   位于判断语句内&＃xff0c;包括 test、if、 while 等等。
   这两个组合在一起用&＃xff0c;可以在 debug 的时候替你节省许多时间。出于防御性编程的考虑&＃xff0c;有必要在写第一行具体的代码之前就插入它们。扪心自问&＃xff0c;写代码的时候能够一次写对的次数有多少&＃xff1f;关注公众号&＃xff1a;程序员大咖 免费领取视频教程。大多数代码&＃xff0c;在提交之前&＃xff0c;通常都经历过反复调试修改的过程。与其在焦头烂额之际才引入这两个配置&＃xff0c;不如一开始就给 debug 留下余地。在代码终于可以提交之后&＃xff0c;再考虑是否保留它们也不迟。

3. 带上shellcheck
   好了&＃xff0c;现在我已经有了三行&＃xff08;样板&＃xff09;代码&＃xff0c;具体的业务逻辑一行都没写呢。是不是该开始写了&＃xff1f;
   且慢&＃xff01;工欲善其事&＃xff0c;必先利其器。这次&＃xff0c;我就介绍一个 shell 脚本编写神器&＃xff1a;shellcheck
   说来惭愧&＃xff0c;虽然写了几年 shell 脚本&＃xff0c;有些语法我还是记不清楚。这时候就要依仗 shellcheck 指点一下了。
   shellcheck 除了可以提醒语法问题以外&＃xff0c;还能检查出 shell 脚本编写常见的 bad code。本来我的N条建议里面&＃xff0c;还有几条是关于这些 bad code 的&＃xff0c;不过考虑到 shellcheck 完全可以发掘出这些问题&＃xff0c;于是忍痛把它们都剔除在外了。毫无疑问&＃xff0c;使用 shellcheck 给我的 shell 编写技能带来了巨大的飞跃。
   所谓“站在巨人的肩膀上”&＃xff0c;虽然我们这些新兵蛋子&＃xff0c;技能不如老兵们强&＃xff0c;但是我们可以在装备上赶上对方啊&＃xff01;动动手安装一下&＃xff0c;就能结识一个循循善诱的“老师”&＃xff0c;何乐而不为&＃xff1f;
   顺便一提&＃xff0c;shellcheck 居然是用 haskell 写的。谁说 haskell 只能用来装逼&＃xff1f;

4. 变量展开
   在 shell 脚本中&＃xff0c;偶尔可以看到这样的做法&＃xff1a;echo $xxx | awk/sed/grep/cut...。看起来大张形势的样子&＃xff0c;其实不过是想修改一个变量的值。
   杀鸡何必用牛刀&＃xff1f;bash 内建的变量展开机制已经足以满足你各种需求&＃xff01;还是老方法&＃xff0c; read the f**k manaul! man bash 然后搜索Parameter Expansion&＃xff0c;下面就是你想要的技巧。键者也写过一篇相关的文章&＃xff0c;希望能助上一臂之力&＃xff1a;玩转 Bash变量。

5. 注意local
   随着代码越写越多&＃xff0c;你开始把重复的逻辑提炼成函数。有可能你会掉到 bash 的一个坑里。在 bash&＃xff0c;如果不加 local 限定词&＃xff0c;变量默认都是全局的。变量默认全局——这跟 js 和 lua 相似&＃xff1b;但相较而言&＃xff0c;很少有 bash 教程一开始就告知你这个事实。在顶级作用域里&＃xff0c;是否是全局变量并不重要。但是在函数里面&＃xff0c;声明一个全局变量可能会污染到其他作用域&＃xff08;尤其在你根本没有注意到这一点的情况下&＃xff09;。所以&＃xff0c;对于在函数内声明的变量&＃xff0c;请务必记得加上 local 限定词。

6. trap 信号
   如果你写过稍微复杂点的在后台运行的程序&＃xff0c;应该知道 posix 标准里面“信号”是什么一回事。如果不知道&＃xff0c;直接看下一段。像其他语言一样&＃xff0c;shell 也支持处理信号。trap sighandler INT可以在接收到 SIGINT 时调用 sighandler 函数。捕获其他信号的方式以此类推。
   不过 trap 的主要应用场景可不是捕获哪个信号。trap 命令支持“捕获”许多不同的流程——准确来说&＃xff0c;允许用户给特定的流程注入函数调用。其中最为常用的是trap func EXIT和trap func ERR。
   trap func EXIT允许在脚本结束时调用函数。由于无论正常退出抑或异常退出&＃xff0c;所注册的函数都能得以调用&＃xff0c;在需要调用一个清理函数的场景下&＃xff0c;我都是用它注册清理函数&＃xff0c;而不是简单地在脚本结尾调用清理函数。
   trap func ERR允许在运行出错时调用函数。一个常用的技法是&＃xff0c;使用全局变量ERROR存储错误信息&＃xff0c;然后在注册的函数中根据存储的值完成对应的错误报告。把原本四分五裂的错误处理逻辑集中到一处&＃xff0c;有时候会起奇效。不过要记住&＃xff0c;程序异常退出时&＃xff0c;既会调用EXIT注册的函数&＃xff0c;也会调用ERR注册的函数。

7. 三思后行
   以上几条都是具体的建议&＃xff0c;剩下两条比较务虚。
   这条建议的名字叫“三思而行”。其实无论写什么代码&＃xff0c;哪怕只是一个辅助脚本&＃xff0c;都要三思而行&＃xff0c;切忌粗心大意。不&＃xff0c;写脚本的时候更要记住这点。毕竟许多时候&＃xff0c;一个复杂的脚本发端于几行小小的命令。一开始写这个脚本的人&＃xff0c;也许以为它只是一次性任务。代码里难免对一些外部条件有些假定&＃xff0c;在当时也许是正常的&＃xff0c;但是随着外部环境的变化&＃xff0c;这些就成了隐藏的暗礁。雪上加霜的是&＃xff0c;几乎没有人会给脚本做测试。除非你去运行它&＃xff0c;否则不知道它是否还能正常使用。
   要想减缓脚本代码的腐烂速度&＃xff0c;需要在编写的时候辨清哪些是会变的依赖、哪些是脚本正常运行所不可或缺的。要有适当的抽象&＃xff0c;编写可变更的代码&＃xff1b;同时要有防御性编程的意识&＃xff0c;给自己的代码一道护城河。

8. 扬长避短
   有些时候&＃xff0c;使用 shell 写脚本就意味着难以移植、难以统一地进行错误处理、难以利索地处理数据。
   虽然使用外部的命令可以方便快捷地实现各种复杂的功能&＃xff0c;但作为硬币的反面&＃xff0c;不得不依靠grep、sed、awk等各种工具把它们粘合在一起。
   如果有兼容多平台的需求&＃xff0c;还得小心规避诸如BSD和GNU coreutils&＃xff0c;bash版本差异之类奇奇怪怪的陷阱。
   由于缺乏完善的数据结构以及一致的API&＃xff0c;shell 脚本在处理复杂的逻辑上力不从心。
   解决特定的问题要用合适的工具。知道什么时候用 shell&＃xff0c;什么时候切换到另外一门更通用的脚本语言&＃xff08;比如ruby/python/perl&＃xff09;&＃xff0c;这也是编写可靠 shell 脚本的诀窍。如果你的任务可以组合常见的命令来完成&＃xff0c;而且只涉及简单的数据&＃xff0c;那么 shell 脚本就是适合的锤子。如果你的任务包含较为复杂的逻辑&＃xff0c;而且数据结构复杂&＃xff0c;那么你需要用 ruby/python 之类的语言编写脚本