如何测试脚本和书写脚本的一些经验分享

学习linux我们,肯定要写大量的脚本,

我之前发布的脚本的文章是直接执行的,那么我们如何测试自己的脚本呢

测试脚本

-n 只读取shell脚本,但不实际执行

-x 进入跟踪方式,显示所执行的每一条命令

-c "string" 从strings中读取命令

"-n"可用于测试shell脚本是否存在语法错误,但不会实际执行命令。

"-c"选项使shell解释器从一个字符串中而不是从一个文件中读取并执行shell命令。

"-x"(执行脚本并显示脚本执行过程)选项可用来跟踪脚本的执行,是调试shell脚本的强有力工具。

直接执行脚本的弊端:

sh test.sh

如果脚本中有错,或者不适用于当前的系统环境,

直接显示找不到,会报错,但是不告诉你脚本出错的具体位置

进行测试的好处

sh -x test.sh

加上-x会显示脚本中具体出错的位置,显示执行的过程,方便我们排错

 

"-n"可用于测试shell脚本是否存在语法错误,但不会实际执行命令。

"-c"选项使shell解释器从一个字符串中而不是从一个文件中读取并执行shell命令。当需要临时测试一小段脚本的执行结果时,可以使用这个选项,如下所示:
sh -c 'a=1;b=2;let c=$a+$b;echo "c=$c"'

"-x"选项可用来跟踪脚本的执行,是调试shell脚本的强有力工具。"-x"选项使shell在执行脚本的过程中把它实际执行的每一个命令行显示出来,并且在行首显示一个"+"号。 "+"号后面显示的是经过了变量替换之后的命令行的内容,有助于分析实际执行的是什么命令。 "-x"选项使用起来简单方便,可以轻松对付大多数的shell调试任务,应把其当作首选的调试手段。
 

书写脚本经验分享:

实际工作生产中,我们是要在公司的服务器环境下进行脚本的编写和测试,所以一定要小心

3种脚本调试命令的适用环境:

 

    1.在shell脚本编写完成之后,实际执行之前,
首先使用"-n"选项来测试脚本是否存在语法错误是一个很好的习惯。
因为某些shell脚本在执行时会对系统环境产生影响,比如生成或移动文件等,
如果在实际执行才发现语法错误,您不得不手工做一些系统环境的恢复工作才能继续测试这个脚本。

    2.当需要临时测试一小段脚本的执行结果时,可以使用这个选项,如下所示:
    sh -c 'a=1;b=2;let c=$a+$b;echo "c=$c"'

    3."-x"选项使shell在执行脚本的过程中把它实际执行的每一个命令行显示出来,
并且在行首显示一个"+"号。 "+"号后面显示的是经过了变量替换之后的命令行的内容,
有助于分析实际执行的是什么命令。 "-x"选项使用起来简单方便,可以轻松对付大多数的shell调试任务,
应把其当作首选的调试手段。

 

我自己之前不经常用这些命令,但是为了适应后面的学习,也在慢慢的用它们

有以下3点原因:

1.我平时写的脚本都是学习一些脚本的基础语法,所以还没有到写影响系统具体服务的脚本(后续就会有了)

所以不怎么影响

2.我在自己创建的虚拟机里执行自己的脚本,虚拟机坏了可以重装

(我写了几个有关虚拟机的脚本还挺好用的,有迁移虚拟机的,克隆虚拟机的,创建虚拟机的,

创建快照的,都是为了方便自己做实验写的,太懒了不想做重复工作)

3.我使用的是自己的个人电脑,最坏的情况是自己在真机中测试脚本,

导致系统崩坏,这个我可以自己装双系统(前提得经常备份自己的数据)

(对于技术小白,不建议在真机中测试自己的脚本)

为了避免上面的问题的解决方法:

我建议最好在虚拟机中做实验,

不是百分百自己写的脚本或者没有经过多次测试的脚本不要在真机中运行

 

 

 

 

GitHub 加速计划 / li / linux-dash
6
1
下载
A beautiful web dashboard for Linux
最近提交(Master分支:3 个月前 )
186a802e added ecosystem file for PM2 4 年前
5def40a3 Add host customization support for the NodeJS version 4 年前
Logo

旨在为数千万中国开发者提供一个无缝且高效的云端环境,以支持学习、使用和贡献开源项目。

更多推荐