I'm trying to run a Python script from the command line as a command on Windows -- so no usage of "Python" or ".py". If my script is named "testing.py", I am attempting to make this name into a command and call "testing" from the command line.
Going through the docs it seems I need to use this shebang #!/usr/bin/env python
as long as I have Python in my PATH.
https://docs.python.org/3/using/windows.html#shebang-lines
I also have the script folder in my PATH, so something like "testing.py" is currently working from the command line.
According to the docs and this tutorial, https://dbader.org/blog/how-to-make-command-line-commands-with-python
I should be able to evoke my Python script just by "testing" if I have the proper paths within PATH and the above shebang. However, I can't seem to get the script running withouth adding ".py".
The accepted answer by @AKX is incorrect for Windows 10 standard Python 3, certainly in the latest Windows 10 (1903) if not earlier.
(Note: I cannot speak to how this may or may not work under WSL.)
I have several versions of Python installed (2.7, 3.6, 3.7, and most recently Python 3.8b1). I've been using the #!/usr/bin/env
shebang for years in my scripts for cross-platform compatibility (usually to distinguish Py2 vs Py3 scripts).
I've created a little script in a folder (C:\so_test\awtest.py
):
#!/usr/bin/env python3.6
import sys
print(sys.version)
If I run this with awtest.py
or just awtest
I get 3.6.x
reported (showing it's running with Python 3.6). If I change the shebang to refer to 3.7, I get 3.7.x
reported. If I change the shebang to just #!/usr/bin/env python3
I get the latest version of Python installed (3.8).
Now, if I add that folder to my path (path=%PATH%;C:\so_test
in the command window you're testing in, or in the main env vars (you will need to restart the command window if you do the latter though)), I can change to a different directory and run awtest
or awtest.py
and they still work and refer to the folder in the path. If I remove the script folder from the path these files are no longer found.
While I wouldn't necessarily expect this to work on Windows prior to 10 or Python 2.7, this functionality appears to be the way of things going forward.