用sh、./、source执行Shell脚本到底有何不同？

要解答这个看似简单的问题，需要先复习一下Linux系统里“命令”这个词的含义。

Linux系统中的命令有两种：一是内置命令，是Shell与生俱来的一部分，比如最基础的cd、echo、kill等；二是外部命令，包含已编译的实用程序以及Shell脚本两种，它们两者又可以统称为可执行文件（executables）。我们平时常用的大多数看起来像“内置（自带）命令”的命令，其实都是/usr/bin及其他目录下的已编译程序，如ls、ps、grep等。

可见，外部命令的实体并不存在于Shell中，而是在调用时才从对应的位置加载。如果用户调用命令时没有提供路径的话，Shell通过PATH环境变量来定位外部命令的路径。

# echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/usr/java/jdk1.8.0_172/bin:/usr/java/jdk1.8.0_172/jre/bin

如果在PATH给定的路径仍然找不到命令，Shell就会返回"command not found"。这也就解释了为什么在Linux下安装完JDK之后，总是要将$JAVA_HOME/bin写入PATH——用户肯定不想每次调用JDK提供的命令时都要先cd到JDK的安装路径，或者把路径写得清清楚楚。

按照上文所述，我们平时自己写的Shell脚本也是外部命令。下面在/tmp/test目录下直接创建一个文件：touch my_script.sh，并在其中写几句简单的话。

#!/bin/sh
echo "Hello World!"
echo "Parameter 1 is: $1"
echo "MYVAR is: $MYVAR"

然后以不同的方式执行这个脚本。

[root@aes ~]# MYVAR=littlemagic
[root@aes ~]# sh /tmp/test/my_script.sh bla
Hello World!
Parameter 1 is: bla
MYVAR is: 
[root@aes ~]# /tmp/test/my_script.sh bla
-bash: /tmp/test/my_script.sh: Permission denied
[root@aes ~]# source /tmp/test/my_script.sh bla
Hello World!
Parameter 1 is: bla
MYVAR is: littlemagic

[root@aes ~]# cd /tmp/test
[root@aes test]# sh my_script.sh bla
Hello World!
Parameter 1 is: bla
MYVAR is: 
[root@aes test]# ./my_script.sh bla
-bash: ./my_script.sh: Permission denied
[root@aes test]# my_script.sh bla
-bash: my_script.sh: command not found
[root@aes test]# source my_script.sh bla
Hello World!
Parameter 1 is: bla
MYVAR is: littlemagic

这段示例的信息量蛮大的，下面以Q&A的形式逐个解决问题。

Q1：./有什么特殊含义没？

并没有，只是表示相对路径（即当前目录）而已，./my_script.sh即在当前目录/tmp/test执行my_script.sh脚本。用绝对路径和用相对路径执行脚本是等价的，因此可以干脆将它们打包统称为“./方式”，以与“sh方式”区分开来。

Q2：为什么./方式提示没权限，而sh方式执行成功？

在./方式下，当前Shell进程会使用fork系统调用产生一个子Shell进程，并使用execve系统调用让OS在子Shell进程中执行脚本。execve系统调用必然会检查脚本文件的权限，而新touch出来的文件权限是-rw-r--r--，并没有可执行（x）权限，所以会报Permission denied。如果把权限改正，那么它的执行结果与sh方式是相同的。

[root@aes test]# chmod a+x my_script.sh
[root@aes test]# ./my_script.sh bla
Hello World!
Parameter 1 is: bla
MYVAR is: 

sh方式的不同点在于，OS会通过sh命令的调用直接产生一个新的Shell进程，并将my_script.sh当作命令行参数传进去。新的Shell进程就会读取、解释并执行该脚本，而OS不关心该文件到底是什么，自然也就不要求可执行权限，只要求读权限就可以了。

Q3：为什么在当前路径下直接写my_script.sh会报command not found？

Linux与Windows不同，如果用户不指定路径，那么就会直接跳过对当前路径的检查，直接按照PATH来查找。而PATH里自然是没有当前路径的，command not found就顺理成章了。也就是说，加./是为了告诉Shell：“我已经确定我要执行的东西在当前路径了”。

看官可能会问，干脆在PATH里直接加上当前路径（即.），不就可以免去打./的麻烦了吗？Linux非常不推荐这样做，安全风险极大。举个极端的例子：一个普通用户在自己的家目录新建了一个名为ls的脚本，但里面的内容是rm -rf /*。然后root用户来到该用户的家目录，并执行ls命令，如果PATH里有当前路径的话，结果可想而知。

Q4：为什么source执行可以打出MYVAR变量的值，其他两种不行？

source是Shell（准确地说是Bash）的内置命令，在Bourne Shell中的等价命令是一个点.，即点命令。用source命令执行脚本文件时，是在当前Shell进程中执行，而不是像./与sh方式一样在新的Shell进程中执行，因此早先设置的变量在脚本里是可以读取到的。

source一般不用来执行业务脚本，最常见用途是在某些初始化脚本修改之后使其立即生效，即source /etc/profile这样。

Bonus Part：shebang对脚本执行的影响

shebang是指脚本文件中以字符#!开头的第一行，它用来指定这个脚本该用哪种解释器来解释。上文中出现的#!/bin/sh就表示应该使用sh（在这里就是Bash）来解释它。

需要注意，只有./方式执行脚本才会读取shebang并调用指定的解释器，而“sh方式”（sh当然可以换成任意其他的解释器）会忽略shebang。举个例子，新建一个Python脚本，但是shebang仍然故意错写：

#!/bin/sh
print "Hello World!"

如果执行./my_script.py的话，会报语法错误，因为Bash不能解释Python；执行python my_script.py是正常的，因为会直接用Python解释器。若把shebang改回正确的#!/usr/bin/python，那么两种方式都能正常执行。

实际上，shebang甚至可以写成任意外部命令（当然不推荐这样做）。举个有趣的栗子，创建脚本rm_self.sh：

#!/bin/rm
echo "I am still here!"

执行sh rm_self.sh，会输出"I am still here!"，并且rm_self.sh文件本身还在。但若是执行./rm_self.sh，则没有任何输出，并且rm_self.sh文件本身消失了。