一、执行脚本的现象

为了测试一个小的功能，写了一个小脚本，类似的内容如下：

#!/bin/sh

echo "start  api  test ......"

for((i=1;i<=10;i++));
do
echo "cur id :" $i;
done
echo "end."

执行一下，“./testEx.sh”,结果报一个错误“sh: 5: Syntax error: Bad for loop variable”。说实话对脚本的编写还是相对少很多的，这个简单的错误勾起了探索一下的想法 。于是把执行的方式改变了下，“bash testEx.sh”,正常运行。然后把文件内容中的“#!/bin/sh”修改为“#!/bin/bash”，即使使用“./testEx,sh”，也可以正常执行。下面就分析一下原因，脚本大佬可以滑走了。

二、原因和解决

通过上述的执行，发现其实问题的产生就在于是使用sh还bash。那么系统是如何区别这两种脚本的呢？首先执行一个命令看看当前默认的脚本执行解释器:

#echo $0
bash

再执行一下命令，看看当前支持哪些脚本的解释器：

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

也可能通过命令来查看具体的执行解释器位置：

tests$ ls /bin/*sh -l
-rwxr-xr-x 1 root root   27016  5月 31  2023 /bin/avahi-publish
-rwxr-xr-x 1 root root 1396520  1月  7  2022 /bin/bash
-rwsr-xr-x 1 root root   44808 11月 24  2022 /bin/chsh
-rwxr-xr-x 1 root root    6963 10月 13  2023 /bin/c_rehash
-rwxr-xr-x 1 root root  125688  3月 23  2022 /bin/dash
-rwxr-xr-x 1 root root    5188  3月 25  2022 /bin/gettext.sh
-rwxr-xr-x 1 root root    2181  2月  7  2022 /bin/gvmap.sh
-rwxr-xr-x 1 root root    4373  5月 24  2023 /bin/instmodsh
-rwxr-xr-x 1 root root   39460  6月  7  2023 /bin/nvidia-bug-report.sh
-rwxr-xr-x 1 root root     900  6月  7  2023 /bin/nvidia-sleep.sh
-rwxr-xr-x 1 root root   14648  2月 16  2023 /bin/pax11publish
lrwxrwxrwx 1 root root       4  5月  5  2023 /bin/rbash -> bash
lrwxrwxrwx 1 root root      21  5月  5  2023 /bin/rsh -> /etc/alternatives/rsh
lrwxrwxrwx 1 root root       4  5月  5  2023 /bin/sh -> dash  #在本机为dash，而不是bash
-rwxr-xr-x 1 root root  846888  8月 24  2023 /bin/ssh
lrwxrwxrwx 1 root root       7  5月  5  2023 /bin/static-sh -> busybox
lrwxrwxrwx 1 root root       8  5月  5  2023 /bin/tclsh -> tclsh8.6
-rwxr-xr-x 1 root root     281  5月  8  2023 /bin/vmware-license-check.sh
-rwxr-xr-x 1 root root     288  5月  8  2023 /bin/vmware-license-enter.sh
-rwxr-xr-x 1 root root   14728  3月 25  2022 /bin/xrefresh

通过上述的命令可以发现，在系统中存在着多个脚本的解释器，默认的使用是bash。但随即又出来一个问题，不同写法和不同的执行方式，到底调用了哪种解释器？把这个弄清楚了，就可以解决问题了。仍然以最开初的例子为例，这里使用以下几种方式来编辑并执行：

1、使用bash testEx.sh执行:

start  api  test ......
cur id : 1  

......  

cur id : 10  

end.

2、在脚本中指定#!/bin/bash,然后执行，结果同上。
3、默认执行，有可能需要增加执行权限，执行结果：

 Syntax error: Bad for loop variable

4、脚本中不指定任何解释器，执行bash testEx.sh，正常执行并显示结果同1。
5、脚本中不指定任何解释器，默认执行，正常执行，结果同上。

上面的5种方式只有3这种情况会出异常，而在前面的命令中发现它调用的是sh->dash。明确使用bash的，正常执行，显示结果；未明确在脚本中指定的，使用系统默认的bash，所以结果均一致。
通过上述例子就可以明白 ：如果使用bash执行脚本或者在脚本中指定bash脚本解释器（#!/bin/bash），则始终以bash脚本解释器来处理脚本；如果脚本 指定为“#!/bin/sh”，则这个标准的解释器会调用其真正链接的解释器，在本文中它链接的是dash。使用默认执行则看系统默认的脚本解释器是如个即可。

三、扩展

"#!"体现在文件中就是一个2字节魔数，魔数开发者应该都清楚，就是代表文件类型的特殊标记，在此处即为可执行的脚本。在“#!”之后，一般是一个脚本解释器的路径，当然这个解释器可以是一个普通认知的解释器，如bash,sh,csh,dash等等，也可以是一个程序。这就看具体的应用方式了。比如下面的例子：

#!/bin/cat
echo "Used cat!"

这个脚本使用Cat命令来处理，直接执行脚本“./testCat.sh”，执行结果为(如果使用bash testCat.sh看看结果是什么？)：

#!/bin/cat
echo "Used cat!"

那么bash和sh在实际的应用中有什么不同呢？一个简单的说法是前者包括后者；或者说后者是前者的一个子集。从前面命令执行也可以看出，bash提供了对posix的支持。所以才可以将循环写成和C语言类似的方式。如果执行“/bin/bash --posix”则会发现它和“/bin/sh”执行的结果一致，这下就明白了吧，sh是bash的posix支持版。

四、总结

脚本用处真得很大，尤其在一些监控、测试的情况下，一个简单的小脚本就可以达到控制程序的目的。特别是粘连一些相关工具如Jenkins和部署时，可以极大的减少代码的工作量并迅速构建迅速部署。当然脚本的缺点也不少，最显著的就是不好调试，对一些复杂的函数和变量往往需要死记硬背。
建议大家都要好好学习一下脚本相关的知识，这样在服务端开发中，会大提高工作效率。原来总以为脚本是运维的事儿，后来才发现大谬。好好学习，犹未晚尔！