Introduction

When a Python script refuses to run in Git Bash on Windows, the script itself is often fine. The failure usually comes from how Git Bash locates the interpreter, handles line endings, or interprets Unix-style execution rules on top of a Windows environment.

Confirm Which Python Git Bash Can See

The first step is to stop guessing and inspect the shell environment that Git Bash is actually using. A script can run from PowerShell or an IDE terminal and still fail in Git Bash because each shell resolves executables differently.

Run these commands inside Git Bash:

1python --version
2python3 --version
3which python
4which python3

If both python and python3 fail, Git Bash cannot find an interpreter on its PATH. If only one command works, use that name consistently in your scripts and documentation. You can also print the exact interpreter path:

python -c "import sys; print(sys.executable)"

That one-liner confirms which binary is running, which is especially useful if you have a Microsoft Store install, a standalone installer, and one or more virtual environments on the same machine.

Run the Script Through the Interpreter First

Before you debug permissions or shebang lines, run the file explicitly:

python my_script.py

If that works, Python is installed correctly and the problem is only with direct execution. If it fails here as well, the issue is likely one of these:

• Git Bash cannot find Python.
• The active virtual environment is missing required packages.
• The script depends on the current working directory.

A simple test script helps separate environment problems from application problems:

1from pathlib import Path
2import sys
3
4print("Python:", sys.executable)
5print("Script:", Path(__file__).resolve())
6print("Working dir:", Path.cwd())

Run it with python my_script.py. If this prints correctly, your Bash setup is working and the remaining issue is in the original script or its dependencies.

Make Direct Execution Work

If you want to run the file as ./my_script.py, Git Bash needs Unix-style hints. The file should start with a shebang and usually needs the execute bit set.

#!/usr/bin/env python3
print("hello")

Then mark it executable:

chmod +x my_script.py
./my_script.py

The shebang matters because Git Bash uses it to choose the interpreter. If your environment only has python and not python3, use a matching shebang:

#!/usr/bin/env python
print("hello")

This is why checking which python and which python3 first saves time. A correct shebang with the wrong interpreter name still fails.

Fix Line Endings and Virtual Environments

Windows line endings can break direct execution in Bash. A file that looks normal in an editor may contain carriage-return characters that confuse the shebang parser.

You can normalize the file like this:

sed -i 's/\r$//' my_script.py

If the repository stores scripts with CRLF line endings, add a .gitattributes rule so the problem does not keep coming back:

*.py text eol=lf

Virtual environments are another common source of confusion. A package may be installed, but not in the interpreter that Git Bash is using. The safest pattern is to activate the environment in Git Bash and install packages through that same interpreter.

1python -m venv .venv
2source .venv/Scripts/activate
3python -m pip install requests
4python my_script.py

Using python -m pip matters because it ties the installation command to the interpreter you will actually run.

Watch for Path and Working-Directory Assumptions

Some scripts fail only in Git Bash because they assume the current directory contains input files. That may be true in one terminal and false in another. Resolve paths relative to the script file instead of the launch directory.

1from pathlib import Path
2
3BASE_DIR = Path(__file__).resolve().parent
4config_file = BASE_DIR / "config.json"
5
6print(config_file.read_text())

This pattern avoids brittle behavior and makes the script behave the same way from Git Bash, PowerShell, CI, and editor run buttons.

Common Pitfalls

Many developers try ./script.py first and assume Python is broken when that fails, even though python script.py works immediately. Another repeated issue is using py from documentation written for Command Prompt; Git Bash may not resolve it the same way. CRLF line endings are also a frequent culprit because they break the shebang while leaving the source code otherwise untouched. Finally, installing dependencies with one interpreter and running the script with another creates confusing import errors that look unrelated to Bash.

Summary

• Start by checking which interpreter names Git Bash can actually resolve.
• Run the file with python my_script.py before debugging direct execution.
• Add a correct shebang and chmod +x if you want to use ./my_script.py.
• Normalize line endings to LF so Bash can parse the file correctly.
• Use virtual environments and python -m pip to keep packages aligned with the runtime interpreter.