我正在学习如何在UNIX中创建shell脚本，但我一直遇到这个愚蠢的错误。假设我制作了一个这样的剧本：
#!/bin/sh
echo HELLO
我将文件保存为测试，并使用chmod 700 test使命令可执行。我将文件保存在我的主目录中，并（尝试）运行该文件，如下所示：
./test
仅限UNIX回复：
./test: Command not found.
发生了什么事？当我输入ls -l时，文件名旁边有一个星号。在我使用chmod命令之前就没有了。谁能告诉我我做错了什么？
答案 0 :(得分：13)
使其可执行：
chmod +x ./test
并确保以Unix文件格式保存文件。并且：检查您的分区是否可执行（mount）。
答案 1 :(得分：10)
这确实非常奇怪。您描述的步骤应该有效，因此您的环境中必须存在一些小错误或执行这些步骤。您可以采取一些措施来帮助诊断：
检查控制字符
只要没有拼写错误或控制字符，您所记录的内容看起来就很好。您应该输入：
进行检查cat -vt ./test
如果您发现任何意外的额外文字可以解释问题。例如，行末尾的“^ M”表示您的编辑器以Windows格式保存文件。
恢复文件可靠性
要创建已知良好的./test2，请复制粘贴以下命令：
`which bash`
printf "#\!`which sh`\necho HELLO\n" > ./test2
chmod +x ./test2
./test2
exit
检查哪个命令无法找到
如果您输入...
./ajio
......你到底得到了什么......
./ajio: Command not found.
...正如您在./test中描述的那样？我刚刚编写了名字ajio，所以它不应该存在。如果他们的消息匹配，那么它并没有真正告诉你任何新的东西。但如果消息不同，则确认./test至少已找到且可执行。
您的sh版本也可能试图告诉您不能找到test，但是在运行test某些命令时shell试图运行找不到。这不应该是echo命令，就像在shell中实现的大多数将是内部命令的shell实现一样。但是，shell可能会运行一个初始化脚本，其中包含一行指定无法运行的命令。如果您运行man sh，它将告诉您shell可能尝试运行的所有不同启动文件。这些可以与以交互方式启动shell时使用的不同。但是，作为一个初学者，检查这些脚本的有效性可能是令人生畏的。任何虚假的定制都可能是你的个人shell启动过程，而不是影响整个Linux安装，所以运行ls -ld ~/.*列出你的主目录中的隐藏文件，并检查任何看起来像shell启动文件（例如〜/ .bashrc，〜/ .profile，〜/ .bash_login）。检查可以找到的任何命令，并在路径变量设置为包含它们的位置后调用。
与另一个壳比较
如果/ bin / sh install / initialisation存在问题，那么您可以通过调用另一个shell来绕过它。尝试...
which zsh
which tcsh
which csh
...如果其中一个或多个找到了替代shell，请编辑或重新创建指定shell的文件，ala ......
#!/bin/csh
echo HELLO
...然后chmod +x它和./ - 运行它。如果可行，那么您知道您的问题是/ bin / sh特定的。
答案 2 :(得分：5)
看起来你需要在bin之前使用斜杠：
#!/bin/sh
# ^
其他所有看起来都很好...我假设/bin/sh是您的可执行文件Bournse shell的位置 - 如果不是，您需要根据需要进行调整。如果没有前导斜杠，那么shell会查找相对于当前目录的bin/sh ，而不是它真正存在的位置。
您需要找到您想要（或需要）脚本的可执行shell解释器。
还有一些建议 - 在我的机器上我得到了这些结果：
# tells you where sh resides, if it is on your path
$ which sh
/bin/sh
# tells you which shell you are currently using
$ echo $SHELL
/bin/tcsh
我可以在简单的shell脚本中使用其中任何一个作为“shebang”行。您可能会发现您的Bourne shell位于/usr/bin而不是/bin。
答案 3 :(得分：3)
首先，检查/ bin / sh是否存在，如果不存在那么那就是你的问题。
如果安装了/ bin / sh，那么如果路径配置不正确，我认为会发生这种情况。
在这种情况下，您可以尝试从test.sh所在的当前工作目录中/bin/sh test.sh。
如果您从Windows复制文件，请尝试dos2unix test.sh。
答案 4 :(得分：2)
当./test是可执行脚本并且执行它时会给出错误消息./test: Command not found，请检查解释器是否存在。您必须提供绝对路径（不使用PATH环境变量）。
如果文件已通过Windows计算机，请确保该行末尾没有虚假回车符，因为CR将成为解释程序文件名的一部分。您可以查看<test head -n 1 | od -t x1：如果以0d 0a结尾，则有CR，您需要将其删除（您可能还需要从其他行中删除CR）。
答案 5 :(得分：1)
我遇到了同样的问题，我将文件从Windows复制到Linux并尝试执行它。我做了上面的所有建议，但没有任何帮助，直到我在文件上执行dos2unix并修复它。你可能不是这样，但只是把它放在那里
答案 6 :(得分：1)
我在旧的SCO OpenServer 5.0.7虚拟机上遇到了类似的问题。开车送我疯了，我无法运行以
开头的某些脚本“＃！/斌/庆典”
（当然减去引号）在阅读这里的线程时，我突然意识到/ bin / bash是否存在。事实证明它失踪了。我从SKUNKWARE2000 CD安装，一切都很顺利。
答案 7 :(得分：0)
#!告诉Unix使用指定的程序执行脚本。在您的情况下，您已指定bin/sh，但它应为/bin/sh。 Unix提供的错误消息并不是特别清楚它找不到哪个程序。
答案 8 :(得分：0)
要添加到Martin的答案，您要说将文件保存在主目录中并将其作为./test运行。仅当您当前的工作目录与主目录相同时，此方法才有效。
文件名旁边的星号表示该文件是可执行的。
答案 9 :(得分：0)