I use Bash on Windows, provided by MSYS.
I tried to run a Python file with a shebang of
#!/usr/bin/env python, but I get this error message:
/usr/bin/env: python: No such file or directory
What can I do to make this work?
I know I can launch the Python file by suffixing it with
python, but I want it to work without the suffix too.
Use the proper path where Python is installed instead, for example:
If you have Unix-like path support on your system (I'm not familiar with MSYS), you can always enter the path to your
python executable, i.e. the output of
What happens when you run (from the shell):
$ /usr/bin/env python
If it starts an interactive python session, then python can be found. (You can also simply run:
type python). If it prints "no such file or directory", then
python isn't being found in your PATH. See if the following can be tweaked to fix the problem (spaces in the path/to/python will probably cause issues):
$ export PATH=$PATH:/path/to/python $ /usr/bin/env python
You might be interested in a Python Launcher For Windows
I turned out to be a mismatch between Virtualenv's
activate.sh file and MSYSGIT. It was never intended to work on Windows.
The root of the problem is that spaces in shebangs are interpreted as supplying additional arguments to an executable, so
C:\Program Files\Python\python.exe gets seen as
Files\Python\python.exe as an argument.
The best solution for this, because Windows LOVES spaces in the
$HOME directory and
Program Files and other places even though it can really break things in cmd.exe and Powershell and other tools, is:
Install Python to
C:\Python and add the
C:\Python folder where
python.exe lives and the
Scripts directory that lives inside it to your
PATH environment variable at the system or user level.
If you need Python 2.7.x and 3.x to co-exist, install them into
C:\Python37 and rename the
python37.exe, etc and add each of those folders and their
Scripts folders into the
PATH. You may want to determine which of the Python 3 versions you want to be the "default" and also make a copy in that folder as
python3.exe to handle any scripts that use
If your user home directory has a space in it, you may also experience issues if you use the
pip install --user somepackage syntax. The
--user defaults to your home directory, and the space will trip up things in this case as well. The workaround is described here but boils down to exporting PYTHONUSERBASE to your environment.
export PYTHONUSERBASE=/myappenv pip install --user SomePackage
or in Windows (Powershell):
$env:PYTHONUSERBASE='C:\PythonPkgs' pip install --user SomePackage
Latest versions of Windows 10 supports installing Linux subsystems. If you run from there paths should be correct.
It should be a working solution if you are okay with running it that way.