CODEWITHSUNDEEP
bashgitshgit-bash
Paul Gilmore
Paul Gilmore

Reputation: 478

Why does ". myscript" return file-not-found in only one Git for Windows sh.exe?

I have downloaded Git from here.

I recently discovered there's two copies of sh.exe, which provides a bash shell.

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

I have come to discover that there's a difference in functionality between the two.

For example, the #1 instance can run a bash script via: . myScript.sh where the #2 instance requires the syntax to be: . ./myScript.sh The #2 instance will report a missing file error if the #1 syntax is used, even if the file exists.

  1. Why are there two instances?
  2. Which one is the "proper" one?
  3. Is there any documentation about the differences between these implementations?
  4. Is there any strong reason I should not use one or the other?
  5. Is the difference in functionality a bug?

Upvotes: 2

Views: 167

Answers (1)

Charles Duffy
Charles Duffy

Reputation: 295345

Why Multiple Shells?

This looks like you have one copy of dash (a minimal /bin/sh implementation -- fast to start up with few bells and whistles) and one copy of bash (a much larger shell with a substantial number of extensions taken from ksh). bash disables some of its extra features when called under the sh name, but not all of them.

One of the "features" bash adds to baseline POSIX sh is searching the current directory for files sourced in with the . or source commands, rather than searching only the PATH as the POSIX sh specification calls for.

Why Do They Differ? Who's Correct?

The relevant standard is at https://pubs.opengroup.org/onlinepubs/009695399/utilities/dot.html; see in particular the first paragraph of the RATIONALE section:

Some older implementations searched the current directory for the file, even if the value of PATH disallowed it. This behavior was omitted from this volume of IEEE Std 1003.1-2001 due to concerns about introducing the susceptibility to trojan horses that the user might be trying to avoid by leaving dot out of PATH .

Older shells searched . in addition to directories in the PATH. However, for security reasons, the POSIX sh specification does not call for this behavior; a user who doesn't put . in the PATH presumably wants to be able to cd into directories the content of which they don't control or trust without worrying about typosquatting or other attacks.

Assuming that the directory containing myscript.sh is not in the PATH, the shell which reports the "file not found" is more strictly compliant than the other.

Upvotes: 2

Related Questions