实现一个简单的类shell脚本解释器 编写 Shell 脚本的最佳实践

11/27 23:27:49 来源网站:辅助卡盟网

命名有标准

所谓命名规范,基本包含下面这几点:

编码要统一在写脚本的时候尽量使用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。权限记得加

这一点虽然很小,但是我个人却经常忘记,不加执行权限会导致无法直接执行,有点讨厌。。。

日志和回显

sftp shell脚本实现_shell 脚本解释器_实现一个简单的类shell脚本解释器

日志的重要性不必多说,能够方便我们回头纠错,在大型的项目里是非常重要的。

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

有时候为了提高用户体验,我们会在回显中添加一些特效,比如颜色啊,闪烁啊之类的,具体可以参考ANSI/VT100 Control sequences这篇文章的介绍。

密码要移除

不要把密码硬编码在脚本里,不要把密码硬编码在脚本里,不要把密码硬编码在脚本里。

重要的事情说三遍,尤其是当脚本托管在类似Github这类平台中时。。。

太长要分行

在调用某些程序的时候,参数可能会很长实现一个简单的类shell脚本解释器,这时候为了保证较好的阅读体验,我们可以用反斜杠来分行:

./configure \
–prefix=/usr \
–sbin-path=/usr/sbin/nginx \
–conf-path=/etc/nginx/nginx.conf \

注意在反斜杠前有个空格。

编码细节规范代码有效率

在使用命令的时候要了解命令的具体做法,尤其当数据处理量大的时候,要时刻考虑该命令是否会影响效率。

比如下面的两个sed命令:

sed -n '1p' file
sed -n '1p;1q' file

shell 脚本解释器_sftp shell脚本实现_实现一个简单的类shell脚本解释器

他们的作用一样,都是获取文件的第一行。但是第一条命令会读取整个文件,而第二条命令只读取第一行。当文件很大的时候,仅仅是这样一条命令不一样就会造成巨大的效率差异。

当然,这里只是为了举一个例子,这个例子真正正确的用法应该是使用head -n1 file命令。。。

勤用双引号

几乎所有的大佬都推荐在使用”$”来获取变量的时候最好加上双引号。

不加上双引号在很多情况下都会造成很大的麻烦,为什么呢?举一个例子:

#!/bin/sh
#已知当前文件夹有一个a.sh的文件
var="*.sh"
echo $var
echo "$var"

他的运行结果如下:

a.sh
*.sh

为啥会这样呢?其实可以解释为他执行了下面的命令:

echo *.sh
echo "*.sh"

在很多情况下,在将变量作为参数的时候,一定要注意上面这一点,仔细体会其中的差异。上面只是一个非常小的例子,实际应用的时候由于这个细节导致的问题实在是太多了。。。

巧用main函数

我们知道,像java,C这样的编译型语言都会有一个函数入口,这种结构使得代码可读性很强,我们知道哪些直接执行,那些是函数。但是脚本不一样,脚本属于解释性语言,从第一行直接执行到最后一行,如果在这当中命令与函数糅杂在一起,那就非常难读了。

    暂无相关资讯
实现一个简单的类shell脚本解释器 编写 Shell 脚本的最佳实践