Quick answer: The /usr/bin/env python error means env cannot find an executable named python on PATH, or the script points to an unavailable interpreter. Use the supported python3 name or a virtual-environment interpreter deliberately, then verify the service’s PATH and permissions.
The usr/bin/env: python: No such file or directory message appears when a script asks env to find an executable named python, but that name is not available on the command path. On many current Linux and macOS systems, the interpreter is exposed as python3 instead. Once the interpreter path problem is clear, Python Shebang Line Usage Guide explains portable shebang forms, executable permissions, and environment selection.
The fix is usually small: change the shebang to python3, run the script with the interpreter that exists, activate the correct virtual environment, or make sure the interpreter directory is reachable through PATH. Do that before changing project code, because the failure happens before Python starts running the file.
This error is different from an import error. If Python starts and then cannot find a package, you will see a ModuleNotFoundError. If env cannot find python, the operating system never reaches the import step.
The same script can behave differently in a terminal, cron job, container, or hosting task because each launch context may use a different command path. Always check the context that produced the error. A script that works in your interactive shell can still fail in automation if that automation has a smaller path list.
The official Python on Unix documentation, sys.executable documentation, shutil.which documentation, pathlib documentation, and Python Packaging virtual environment guide are useful references.
Use python3 In The Shebang
A shebang is the first line of an executable script. If the file starts with #!/usr/bin/env python, env searches for an executable called python. Use python3 when that is the available command.
#!/usr/bin/env python3
import sys
print("Python executable:")
print(sys.executable)
After changing the first line, run the script again. If the file itself is executable, the operating system uses the shebang. If you run python3 script.py directly, the shebang is not the deciding factor.
Check Which Interpreter Names Exist
Use shutil.which() from Python to check which executable names are visible on the current command path.
from shutil import which
for command in ["python", "python3"]:
location = which(command)
if location:
print(f"{command}: {location}")
else:
print(f"{command}: not found")
If python3 exists and python does not, a python shebang will fail. If neither name exists, install Python or use the full interpreter path provided by your hosting panel, package manager, or virtual environment.
Rewrite A Shebang Safely
If a project has an old script that still points to python, update only the first line and leave the rest of the file unchanged.
from pathlib import Path
path = Path("script.py")
lines = path.read_text(encoding="utf-8").splitlines()
if lines and lines[0] == "#!/usr/bin/env python":
lines[0] = "#!/usr/bin/env python3"
path.write_text("\n".join(lines) + "\n", encoding="utf-8")
This avoids accidental edits in the body of the script. Review the diff before committing, especially if the file contains generated code or platform-specific launch instructions.
Use The Active Virtual Environment
When a virtual environment is active, sys.executable points at the interpreter inside that environment. That path is the safest interpreter to use for helper commands launched by Python.
import sys
from pathlib import Path
interpreter = Path(sys.executable)
print(interpreter)
print(interpreter.exists())
print(interpreter.name)
If the printed path is inside your project environment, your script is using the expected interpreter. If it points to a system path when you expected a project environment, activate the environment again before running the script.
Scan Scripts For Old Shebangs
In a repository with several scripts, scan the first line of each Python file and report files that still ask for python instead of python3.
from pathlib import Path
def old_shebangs(root):
for path in Path(root).rglob("*.py"):
first_line = path.read_text(encoding="utf-8").splitlines()[:1]
if first_line == ["#!/usr/bin/env python"]:
yield path
for path in old_shebangs("scripts"):
print(path)
This check is simple enough for a maintenance script or pre-commit hook. It helps prevent the same launch error from returning after older files are copied into a newer project.
Run Child Python Processes Correctly
If one Python script starts another Python script, use sys.executable instead of hard-coding python. That keeps child processes aligned with the interpreter that is already running.
import subprocess
import sys
result = subprocess.run(
[sys.executable, "-c", "print('child process ok')"],
check=True,
capture_output=True,
text=True,
)
print(result.stdout.strip())
This matters in virtual environments, CI jobs, cron tasks, and hosting platforms where python, python3, and the active interpreter may not be the same executable.
Fix Checklist
Start with the exact script that fails. Check its first line. If it says #!/usr/bin/env python, change it to #!/usr/bin/env python3 unless your platform intentionally provides python. Then confirm that python3 exists on the command path.
If the script belongs to a project environment, activate that environment and check sys.executable. For scheduled jobs, CI, or hosting tasks, use the full interpreter path when the command path is minimal. For subprocess calls, pass sys.executable so child commands use the same Python installation.
Once the interpreter is reachable, rerun the script. If a new package import error appears, the original env problem is fixed and you can handle dependencies separately.
Keep the fix narrow. Do not rename project files or reinstall unrelated packages until you have confirmed the interpreter lookup. Most cases are solved by using python3, activating the intended environment, or calling the exact interpreter path that already exists on the system.
Understand The Shebang
The first line tells the operating system how to launch an executable script. /usr/bin/env searches PATH, so the result depends on the user, shell, service manager, container, and environment where the script runs.
Choose python3 Deliberately
On systems where Python 3 is named python3, use an env python3 shebang rather than assuming python is an alias. Check the target platform’s policy before changing a shared script.
Use A Virtual Environment
An activated shell is not the only way to select an environment. A direct shebang to the environment’s interpreter or an explicit launcher makes scheduled and service execution less dependent on interactive state.
Compare Interactive And Service Environments
A service may have a different PATH, working directory, user, permissions, and environment variables. Print or inspect these values in a safe diagnostic rather than assuming the terminal environment applies.
Check More Than The Interpreter
After the executable is found, verify file permissions, line endings, dependencies, and the working directory. A no-such-file error can also come from a malformed shebang or an interpreter path that no longer exists.
The Python Unix documentation describes executable scripts and interpreter selection. Related references include pip and interpreter paths, package environments, and import diagnosis.
For related environment fixes, compare interpreter paths, package environments, and import diagnosis when a script cannot launch.
Frequently Asked Questions
Why does /usr/bin/env python fail?
The operating system cannot find an executable named python on PATH, or the script points to an unavailable interpreter.
Should I change python to python3 in the shebang?
On systems where Python 3 is named python3, use an env python3 shebang or the virtual environment’s interpreter deliberately.
How do I use a virtual environment in a script?
Activate it for interactive work or point the shebang to the environment’s interpreter so the script does not depend on shell activation.
Why does the script work in a terminal but not as a service?
Services may have a different PATH, working directory, user, or environment from your interactive shell.