为什么“。myscript”仅在Windows的一个Git sh.exe中返回文件未找到？

Question

我已经从here下载了Git。

我最近发现sh.exe有两个副本，提供了bash shell。

1. C:\Program Files\Git\bin\sh.exe
2. C:\Program Files\Git\usr\bin\sh.exe

我发现两者之间的功能有所不同。

例如，＃1实例可以通过以下方式运行bash脚本：. myScript.sh，其中＃2实例要求的语法为：. ./myScript.sh如果＃2实例将报告缺少文件错误，即使文件存在，也使用＃1语法。

1. 为什么有两个实例？
2. “正确”的是哪个？
3. 是否有关于这些实现之间差异的文档？
4. 我是否有强烈的理由不应该使用其中一个？
5. 功能上的区别是错误吗？

Answer 1

为什么要使用多个壳？

这似乎是您拥有dash的一个副本（最小的/bin/sh实现-只需很少的花哨就可以快速启动）和bash的一个副本（更大的副本）带有大量ksh扩展名的shell）。以bash的名称调用时，sh会禁用 some 的某些额外功能，但不是全部。

bash添加到基准POSIX sh的“功能”之一是在当前目录中搜索使用.或source命令生成的文件，而不是仅搜索PATH作为POSIX sh规范要求。

---

为什么它们不同？谁是正确的？

相关标准位于https://pubs.opengroup.org/onlinepubs/009695399/utilities/dot.html；特别请参阅RATIONALE部分的第一段：

  

即使PATH的值不允许，某些较旧的实现也会在当前目录中搜索该文件。由于担心将特洛伊木马引入用户可能试图通过将点放在PATH之外来避免的特洛伊木马程序，因此从IEEE Std 1003.1-2001的卷中忽略了此行为。

除.中的目录之外，较旧的外壳程序还搜索PATH。但是，出于安全原因，POSIX sh规范不要求这种行为。未将.放入PATH的用户可能希望能够cd进入他们不控制或不信任的内容的目录，而不必担心域名抢注或其他攻击。

假定包含myscript.sh的目录不在PATH中，则报告“找不到文件”的外壳比其他外壳更严格。