运行脚本的./和sh有什么区别？
我写了一个简单的脚本。 当我运行sh ，我得到了正确的输出，但是当我运行./ ，我收到了一个错误。
我什么时候和./ ？有什么区别？
通过将文件名传递给脚本解释程序来运行任何脚本时，您将运行解释程序，并将脚本作为传递给它的参数。 例如，这看起来像是带有参数’filename.sh’的进程’sh’。 sh解释器正在打开文件。
另一方面，如果您自己运行脚本，系统会调用指定的解释程序并输入脚本内容。 在这种情况下，该过程看起来像’filename.sh’，没有参数。
你应该确保你有一个爆炸线：
#!/bin/bash # bash script here
bang line是脚本中的第一行 ，以相同的两个字符开头#! ，这些是系统在尝试执行脚本时读取的内容，然后系统立即将脚本传递给程序。 请注意，这一行与bash无关，对python和perl也同样适用，即使它们是非常不同的语言。 您可以使用#!/usr/bin/python作为示例，然后使用python代码进行操作。
获得脚本后，请确保已设置执行权限：
chmod a+x filename.sh
然后，您可以将脚本作为自己的进程运行：
./filename.sh
或者将文件放入一个具有良好程序名称的已知位置，例如/usr/sbin并从任何地方运行：
sudo cp filename.sh /usr/sbin/program-name program-name
这实际上是使用具有正确权限的爆炸线的实际好处 – 这都是关于部署的 。 如果用户必须记住运行脚本的程序，那么很难让用户运行脚本。 请记住每次要运行脚本时都要提供完整的脚本路径。 例如，将它放在/usr/local/bin中，并使其可执行，可以为尝试使用脚本的人节省大量的悲伤。 然后，这些程序可供计算机上的所有用户使用。
这也有利于识别。 如果你进入top程序，没有bang行运行的脚本将只有解释器的名称，即bash ， perl或python 。 但是，如果使用正确的权限运行脚本，则会显示脚本的名称。
注意：如果要分发每个人都可以访问的脚本，请创建一个手册页和一个deb软件包来安装它。 我们需要减少在线随机脚本的数量，并增加可以卸载的deb数量。
简短版本：
-
sh是命令行解释器（破折号）。
运行sh my_script使破折号解释脚本。 -
./试图通过查看第一行来找出要使用的解释器。 例如#!/bin/bash，甚至#!/bin/ruby（因为反对运行ruby my_script）。
你做的不同是，
-
使用
sh，您运行的程序将解释脚本中的行，就像您在终端的交互式提示符上键入它们一样， -
使用
./你正在创建一个快捷方式，假设脚本就在你所在的当前目录中，并且它将是可执行的（因为例如你发布了chmod +x myscript.sh），为你节省了宝贵的时间。未来时间:-)
您可能会收到错误的主要原因有三个：
- 该文件不可执行
运行chmod +x来解决这个问题 - 分区不允许运行脚本（已安装“
noexec”）
将脚本复制到/usr/local/bin -
#!line有错误
确保第一行是#!/bin/sh或#!/bin/bash
如果您的第一行看起来正确，但仍然无法正常工作，请确保该文件没有DOS行结尾。
错误看起来像这样：
$ ./myscript.sh bash: ./myscript.sh: /bin/bash^M: bad interpreter: No such file or directory
您可以通过运行dos2unix 来修复它，或者如果您没有，
perl -p -i -e 's/\r\n$/\n/' 。
答案是sh是非常受欢迎的shell的名称。 但过时并被其他人取代。 现在sh与安装在机器上的其他shell相关联。 比如我在那里打了一拳。 从sh运行任何shell通常会触发一些原始“shell”行为的“兼容性”模式。
所以解决方案很简单。 查看sh命令（ls -al / bin / sh）背后的内容，并将＃！/ bin / whatever_you_find_there作为第一行（或者如果脚本中有类似的内容编辑它）。
或者，脚本本身可能存在一些错误。 喜欢sh所满足的依赖，但不是实际使用的解释器。
mkdir ~/bin ; cp myscript.sh ~/bin/ echo "export PATH="$PATH:/home/$USER/bin" >> ~/.profile ; source ~/.profile ;
不是/usr/sbin ，对于非必要的管理工具， /usr/local/bin是一个更好的选择，如果你不想拥有~/bin/ ，但建议尽量避免使用sudo 。