当bash解释命令行时，它在环境变量$PATH中描述的位置中查找命令。要查看它键入:

echo $PATH

你会有一些用冒号分隔的路径。正如您将看到的当前路径。通常不在$PATH中。因此，如果您的命令在当前目录中，Bash就无法找到它。你可以通过以下方式更改:

PATH=$PATH:.

这一行添加了当前目录在$PATH中，所以你可以这样做:

manage.py syncdb

不建议使用，因为它有安全问题，而且你可能会有奇怪的行为。取决于你所在的目录:)

避免:

PATH=.:$PATH

因为你可以“屏蔽”一些标准命令，并打开安全漏洞的大门:)

这只是我的个人意见。

所有这些都有很好的答案，是的，这只适用于在当前目录上运行时，除非你包含绝对路径。请参阅下面的示例。

此外，当我在子文件夹tmp2 (/tmp/tmp2)上有命令时，(点-斜杠)对我来说是有意义的，它使用(双点-斜杠)。

示例:

[fifiip-172-31-17-12 tmp]$ ./StackO.sh

Hello Stack Overflow

[fifi@ip-172-31-17-12 tmp]$ /tmp/StackO.sh

Hello Stack Overflow

[fifi@ip-172-31-17-12 tmp]$ mkdir tmp2

[fifi@ip-172-31-17-12 tmp]$ cd tmp2/

[fifi@ip-172-31-17-12 tmp2]$ ../StackO.sh

Hello Stack Overflow

这个问题已经有了一些很棒的答案，但我想补充一点，如果你的可执行文件在PATH上，当你运行时，你会得到非常不同的输出

./executable

和你逃跑后得到的那些人

executable

(假设您遇到了一个错误消息，而不是另一个)，那么问题可能是您的机器上有两个不同版本的可执行文件:一个在路径上，另一个不在路径上。

通过运行

这可执行

and

whereis executable

它解决了我的问题……我有三个版本的可执行文件，其中只有一个是针对环境正确编译的。

When you include the '.' you are essentially giving the "full path" to the executable bash script, so your shell does not need to check your PATH variable. Without the '.' your shell will look in your PATH variable (which you can see by running echo $PATH to see if the command you typed lives in any of the folders on your PATH. If it doesn't (as is the case with manage.py) it says it can't find the file. It is considered bad practice to include the current directory on your PATH, which is explained reasonably well here: http://www.faqs.org/faqs/unix-faq/faq/part2/section-13.html

/ POSIX PATH规则的基本原理

在bash中运行可执行文件或脚本名称前为什么需要。/(点-斜杠)?但我想更详细地解释为什么我认为这是一个好的设计。

首先，该规则的明确完整版本是:

如果路径包含/(例如./someprog， /bin/someprog， ./bin/someprog):使用CWD而不使用path 如果路径不包含/(例如someprog):使用path而不使用CWD

现在，假设运行:

someprog

将搜索:

首先相对于CWD 之后相对于PATH

然后，如果你想从你的发行版运行/bin/someprog，并且你做了:

someprog

它有时会工作，但有时会失败，因为您可能在包含另一个不相关的someprog程序的目录中。

因此，您很快就会发现这是不可靠的，当您想要使用PATH时，您最终将总是使用绝对路径，因此违背了PATH的目的。

这也是为什么在PATH中使用相对路径是一个非常糟糕的主意。我在看你，node_modules/bin。

相反，假设运行:

./someprog

将搜索:

相对于PATH优先 相对于CWD后

然后，如果你只是从git存储库下载了一个脚本someprog，并希望从CWD运行它，你永远不会确定这是实际运行的程序，因为可能你的发行版有一个:

/bin/someprog

这是在你的PATH中，来自去年圣诞节后你喝多了之后安装的某个软件包。

因此，再一次，你将被迫总是运行本地脚本相对于CWD的完整路径，以知道你在运行什么:

"$(pwd)/someprog"

这也会非常烦人。

你可能会想到的另一个规则是:

相对路径只使用PATH，绝对路径只使用CWD

但这再次迫使用户总是使用绝对路径的非path脚本“$(pwd)/someprog”。

/路径搜索规则为about问题提供了一个简单的解决方案:

斜杠:不要使用PATH no /:只使用PATH

由于当前目录中的文件可以表示为./somefile或somefile，因此它为其中一个文件赋予了特殊含义，因此非常容易知道您正在运行什么。

有时，有点烦人，你不能搜索一些/prog相对于PATH，但我没有看到一个更理智的解决方案。

在*nix上，与Windows不同，当前目录通常不在$PATH变量中。因此，在执行命令时不搜索当前目录。你不需要。/来运行应用程序，因为这些应用程序在你的$PATH;它们很可能在/bin或/usr/bin中。