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

11/27 23:27:49 来源网站:seo优化-辅助卡盟平台

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

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

前言由于工作需要,最近重新开始拾掇shell脚本。虽然绝大部分命令自己平时也经常使用,但是在写成脚本的时候总觉得写的很难看。而且当我在看其他人写的脚本的时候,总觉得难以阅读。毕竟shell脚本这个东西不算是正经的编程语言实现一个简单的类shell脚本解释器,他更像是一个工具,用来杂糅不同的程序供我们调用。因此很多人在写的时候也是想到哪里写到哪里,基本上都像是一段超长的main函数,不忍直视。同时,由于历史原因,shell有很多不同的版本,而且也有很多有相同功能的命令需要我们进行取舍,以至于代码的规范很难统一。考虑到上面的这些原因,我查阅了一些相关的文档,发现这些问题其实很多人都考虑过,而且也形成了一些不错的文章,但是还是有点零散。因此我就在这里把这些文章稍微整理了一下,作为以后我自己写脚本的技术规范。代码风格规范开头有“shebang”所谓shebang其实就是在很多脚本的第一行出现的以#!开头的注释,他指明了当我们没有指定解释器的时候默认的解释器,一般可能是下面这样:

#!/bin/bash

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

$ cat /etc/shells
#/etc/shells: valid login shells
/bin/sh
/bin/dash
/bin/bash
/bin/rbash
/usr/bin/screen

当我们直接使用./a.sh来执行这个脚本的时候,如果没有shebang,那么它就会默认用$SHELL指定的解释器,否则就会用shebang指定的解释器。这种方式是我们推荐的使用方式。代码有注释

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

注释的意义不仅在于解释用途,而在于告诉我们注意事项,就像是一个README。

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

参数要规范

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

最少,最少,我们至少得判断下参数的个数吧:

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

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

变量和魔数

一般情况下我们会将一些重要的环境变量定义在开头,确保这些变量的存在。

source /etc/profile
export PATH=”/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin:/apps/bin/”

这种定义方式有一个很常见的用途,最典型的应用就是,当我们本地安装了很多java版本时,我们可能需要指定一个java来用。那么这时我们就会在脚本开头重新定义JAVA_HOME以及PATH变量来进行控制。

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

缩进有规矩

对于shell脚本,缩进是个大问题。因为很多需要缩进的地方(比如if,for语句)都不长,所有很多人都懒得去缩进,而且很多人不习惯用函数,导致缩进功能被弱化。

其实正确的缩进是很重要的,尤其是在写函数的时候,否则我们在阅读的时候很容易把函数体跟直接执行的命令搞混。

常见的缩进方法主要有”soft tab”和”hard tab”两种。

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