Shell语言-14-Shell特性

1.1 代码风格规范

开头有"蛇棒"所谓shebang其实就是在很多脚本的第一行出现的以"#!"开头的注释，它指明了当我们没指定解释器的时候默认的解释器，一般有以下几种:
#! /bin/sh
#! /bin/bash 等等

直接使用./a.sh来执行脚本的时候，如果没用shebang,就会默认用$shell指定的解释器，否则就会用shebang指定的解释器。也可以用下面的方式来指定

#！ /usr/bin/env bash

1.2 代码要有注释

注释，显然是一个常识，不过这里还是要再强调一下，这个在shell脚本里尤为重要。因为很多单行的shell命令不是那么浅显易懂，没有注释的话在维护起来会让人尤其的头大。
　　注释的意义不仅在于解释用途，而在于告诉我们注意事项，就像是一个README。
　　具体的来说，对于shell脚本，注释一般包括下面几个部分：
shebang
脚本的参数
脚本的用途
脚本的注意事项
脚本的写作时间，作者，版权等
各个函数前的说明注释
一些较复杂的单行命令注释

1.3 参数要规范

这一点很重要，当我们的脚本需要接受参数的时候，我们一定要先判断参数是否合乎规范，并给出合适的回显，方便使用者了解参数的使用。
　　最少，最少，我们至少得判断下参数的个数吧：
　　参数要规范:
if [[$# !=2]];then
echo “Parameter incorrect”
exit 1
fi

1.4 变量

一般情况下我们会将一些重要的环境变量定义在开头，确保这些变量的存在。
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.5 缩进

1.6 命名有标准

1.7 编码要统一

1.8 权限记得加

1.8.1 chmod a+x

chmod a+x的含义

版权

u 表示用户
g 表示用户组
o 表示其它
a 表示所有

chmod a+x a.txt 等价于 chmod +x a.txt 给所用户给予a.txt文件可执行权限

chmod u+x a.txt a.txt文件的所有用户可执行权限

chmod g+x a.txt a.txt用户组可执行权限

chmod o+x a.txt a.txt其他用户可执行权限

1.9 日志和回显

1.10 密钥要移除

1.11 太长要分行

1.12 学会查路径

很多情况下，我们会先获取当前脚本的路径，然后一这个路径为基准，去找其他的路径。通常我们是直接用pwd以期获得脚本的路径。
　　不过其实这样是不严谨的，pwd获得的是当前shell的执行路径，而不是当前脚本的执行路径。
　　正确的做法应该是下面这两种：

script_dir=$(cd $(dirname KaTeX parse error: Expected 'EOF', got '&' at position 4: 0) &̲& pwd) script_…(dirname $(readlink -f $0 ))

　应当先cd进当前脚本的目录然后再pwd，或者直接读取当前脚本的所在路径。

1.13 代码要简短

1.14 代码有效率

在使用命令的时候要了解命令的具体做法，尤其当数据处理量大的时候，要时刻考虑该命令是否会影响效率。
　　比如下面的两个sed命令：

他们的作用一样，都是获取文件的第一行。但是第一条命令会读取整个文件，而第二条命令只读取第一行。当文件很大的时候，仅仅是这样一条命令不一样就会造成巨大的效率差异。
　　当然，这里只是为了举一个例子，这个例子真正正确的用法应该是使用 head -n 1 file 命令。。。
　　勤用双引号
　　几乎所有的大佬都推荐在使用”$”来获取变量的时候最好加上双引号。
　　不加上双引号在很多情况下都会造成很大的麻烦，为什么呢？举一个例子：
　　
　他的运行结果如下：
　
为啥会这样呢？其实可以解释为它执行了下面的命令：就是一个是打印出字符串一个是打印出所有脚本

在很多情况下，在将变量作为参数的时候，一定要注意上面这一点，仔细体会其中的差异。上面只是一个非常小的例子，实际应用的时候由于这个细节导致的问题实在是太多了。。。
　　巧用main函数
　　我们知道，像java，C这样的编译型语言都会有一个函数入口，这种结构使得代码可读性很强，我们知道哪些直接执行，那些是函数。但是脚本不一样，脚本属于解释性语言，从第一行直接执行到最后一行，如果在这当中命令与函数糅杂在一起，那就非常难读了。
　　用python的朋友都知道，一个合乎标准的python脚本大体上至少是这样的：
　　
　他用一个很巧妙的方法实现了我们习惯的main函数，使得代码可读性更强。
　　在shell中，我们也有类似的小技巧:
　　
我们可以采用这种写法，同样实现类似的main函数，使得脚本的结构化程度更好。
　　考虑作用域
　　shell中默认的变量作用域都是全局的，比如下面的脚本：
　　
他的输出结果就是2而不是1，这样显然不符合我们的编码习惯，很容易造成一些问题。
　　因此，相比直接使用全局变量，我们最好使用local readonly这类的命令，其次我们可以使用declare来声明变量。这些方式都比使用全局方式定义要好。
　　巧用heredocs
　　所谓heredocs，也可以算是一种多行输入的方法，即在”<<”后定一个标识符，接着我们可以输入多行内容，直到再次遇到标识符为止。
　　使用heredocs，我们可以非常方便的生成一些模板文件：
　　

1.15 使用新的写法

1.16 其他小 Tip

考虑到还有很多零碎的点，就不一一展开了，这里简单提一提。

1.路径尽量保持绝对路径，不容易出错，如果非要用相对路径，最好用./修饰
2.优先使用bash的变量替换代替awk sed，这样更加简短
3.简单的if尽量使用&& ||，写成单行。比如[[ x > 2]] && echo x
4.当export变量时，尽量加上子脚本的namespace，保证变量不冲突
5.会使用trap捕获信号，并在接受到终止信号时执行一些收尾工作
6.使用mktemp生成临时文件或文件夹
7.利用/dev/null过滤不友好的输出信息
8.会利用命令的返回值判断命令的执行情况
9.使用文件前要判断文件是否存在，否则做好异常处理
10.不要处理ls后的数据(比如ls -l | awk ‘{ print $8 }’)， ls的结果非常不确定，并且平台有关
11.读取文件时不要使用for loop而要使用while read