I am using Windows 10 and have Python installed. The new update brought bash to windows, but when I call python from inside bash, it refers to the Python installation which came with the bash, not to my Python installed on Windows. So, for example, I can't use the modules which I have already installed on Windows and would have to install them separately on the bash installation.
How can I (and can I?) make bash point to my original Windows Python installation? I see that in /usr/bin I have a lot of links with "python" inside their name, but I am unsure which ones to change, and if changing them to Windows directories would even work because of different executable formats.
As of Windows 10 Insider build #14951, you can now invoke Windows executables from within Bash.
You can do this by explicitly calling the absolute path to an executable (e.g. c:\Windows\System32\notepad.exe), or by adding the executable's path to the bash path (if it isn't already), and just calling, for example, notepad.exe.
Note: Be sure to append the .exe to the name of the executable - this is how Linux knows that you're invoking something foreign and routes the invocation request to the registered handler - WSL in this case.
So, in your case, if you've installed Python 2.7 on Windows at C:\, you might invoke it using a command like this from within bash:
$ /mnt/c/Python2.7/bin/python.exe
(or similar - check you have specified each folder/filename case correctly, etc.)
HTH.
I do not have Windows 10 installed, but I use Babun and I had the same problem. As I read aliases work well in Windows 10 shell so simply add alias in your .bashrc pointing to your Python installation directory:
alias python /mnt/c/Python27/python
You have at least four options:
Specify the complete absolute path to the python executable you want to use.
Define an alias in your .bashrc file
Modify the PATH variable in your .bashrc file to include the location of the python version you wish to use.
Create a symlink in a directory which is already in your PATH.
Related
Good day!
Installed the Python 3.9.1, checked "Add to path", the cmd did not work though.
Added Environment Variable Path, both folder
C:\Users\XXXXX\AppData\Local\Programs\Python\Python39
(file manager opens the path to python.exe just fine)
and script lines:
C:\Users\XXXXX\AppData\Local\Programs\Python\Python39
Still the commands python -version and pip --version do not work from the command line.
Py --version works just fine though.
Anyone might share and idea what might be the reason?
This happens more often than one would think.
When you installed python from python.org and follow the installer, post install, you should check your environment variables, and verify that you have no other python installation (or if you do just name them appropriately).
Often you can find that there is an Environment Variable, that includes a python version on the global Environment Variable Path.
To verify that you are targeting the correct python version put these two directories (replace, user and python version), at the top of your PATH (user's path), and check that there are no conflicts with the rest of the PATH variables.
C:\Users\XXXXX\AppData\Local\Programs\Python\PythonXX
C:\Users\XXXXX\AppData\Local\Programs\Python\PythonXX\Scripts
If you had Python installed in the system before, the new path is added at the end of PATH system variable and when system looks for python.exe it finds first the old version that is available under a different folder.
If you used a command window opened before the new version got installed, it is also possible that system variables did not reload. Close it and use a new one to check.
I am trying to get a django project up and running, and I have django running, but I am having trouble with python's virtualenv.
here is my error (on terminal open this shows up)
/Library/Frameworks/Python.framework/Versions/2.7/Resources/Python.app/Contents/MacOS/Python: No module named virtualenvwrapper
virtualenvwrapper.sh: There was a problem running the initialization hooks.
If Python could not import the module virtualenvwrapper.hook_loader,
check that virtualenvwrapper has been installed for
VIRTUALENVWRAPPER_PYTHON=/Library/Frameworks/Python.framework/Versions/2.7/bin/python and that PATH is
set properly.
Here is what My .bash profile looks like:
# Setting PATH for Python 3.4
# The orginal version is saved in .bash_profile.pysave
PATH="/Library/Frameworks/Python.framework/Versions/3.4/bin:${PATH}"
export PATH
# Setting PATH for Python 2.7
# The orginal version is saved in .bash_profile.pysave
PATH="/Library/Frameworks/Python.framework/Versions/2.7/bin:${PATH}"
export PATH
export WORKON_HOME=$HOME/.virtualenvs
source /Library/Frameworks/Python.framework/Versions/3.4/bin/virtualenvwrapper.sh
export PIP_VIRTUALENV_BASE=$WORKON_HOME
if which rbenv > /dev/null; then eval "$(rbenv init -)"; fi
I am pretty new to command line stuff and virtual environments, so I might not know some "obvious" things I am doing wrong. Thanks.
First some basics of the command-line shell:
PATH is an environment variable that contains a list of filesystem directories. When you type a command such as ls, python or virtualenvwrapper.sh your shell will search each directory starting from the first one listed. To see your current PATH type:
$ echo $PATH
/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin
To see what a given command is going to resolve to the location of the program that is going to be run, use the which command:
$ which ls
/bin/ls
Now in your example you are first adding a Python 3.4 location to your PATH and then a Python 2.7 location. The latter location is going to be first on your PATH. So all your Python related commands are first going to try and run Python 2.7, if a command isn't found there, it next searches in your Python 3.4 installation.
You appear to have installed virtualenvwrapper for Python 3.4, but when you run virtualenvwrapper.sh from the line:
source /Library/Frameworks/Python.framework/Versions/3.4/bin/virtualenvwrapper.sh
You are explicitly running the virtualenvwrapper.sh installed for Python 3.4. This runs a python command where your Python 2.7 is run, which does not appear to have virtualenvwrapper installed, as shown by this error message:
/Library/Frameworks/Python.framework/Versions/2.7/Resources/Python.app/Contents/MacOS/Python: No module named virtualenvwrapper
If you tried removing the Python 2.7 location addition to your PATH and it didn't work, you have to remember that changes to your .bash_profile are not automatically reflected in your terminal. You have to create a new terminal session and that new session will read your new .bash_profile.
If you are trying to get the command virtualenv to resolve to two different Pythons, it's simply not possible. It will always resolve to one specific Python based on the ordering of the locations on your PATH. VirtualEnv does install alternate versions of the command with the version of the Python built into the name. Use the commands virtualenv-3.4 and virtualenv-2.7 to create virtual environments for each different Python.
The key to all of this is remembering that PATH is used to resolve to an absolute path location of a program this is run. Use the echo $PATH and which commands to help you understand how that final path is being resolved.
It may seem tedious, but typing out the full absolute path is always going to side-step the magic of PATH resolution:
$ /Library/Frameworks/Python.framework/Versions/2.7/bin/virtualenv
Try using smaller steps on your way to manipulating the path. Use just virutalenv-3.4 to make a Python 3.4 virtual environment and only bring in virtualenvwrapper as you need it and after your understanding of shell environments is more solid.
Finally, even pro's can get tripped up by playing games manipulating the path. You are ultimately trying to take a bunch of different application locations and flatten them all into one namespace. At some point conflicts can become unresolveable. A Python installation tool such as Buildout has it's own learning curve, but it hard-codes the absolute path to the python of each python script that it installs. Hard-coding absolute paths is the only way to deal with extreme corner cases such as having two builds of Python 3.4 side-by-side where you have two scripts which each need to run on two different builds of the same Python. Hard-coding absolute locations is also desirable in production environments, because then your application is immune to any changes to the bash shell. If you forget about a required ordering of your PATH, or another sysadmin tinkers with the PATH, you won't find your application breaking unexpectedly.
I have always used a mac to write and run python scripts. However, I have a bunch of files on a PC that I need to run a script on. I have never really used a PC and don't know how to run the script.
If I go to the command program on the PC and type in python, nothing happens. How do I find where the python path is in order to get into the python prompt? Also, once I am in the prompt, is the importing of modules the same as in a Unix system?
Python isn't added to the system environment's PATH variable by default on windows. You have to either add the path to the directory containing the Python.exe file to the PATH variable, or call python explicitly.
This issue has been addressed in the Python documentation:
Python Documentation: # How to run a Python program under windows
Assuming Python is installed, it is usually placed in a folder prefixed with "Python" and the major/minor version. E.g. C:\Python26
I have 3 versions of Python (2.5, 2.7, 3.2) installed on a Windows machine, 2.5 being the default one (first in PATH and default for open action).
Now the weird thing appear when I run a python script with filename.py (without specifying the interpreter) or by clicking the file in Explorer: Python 2.5 is running the script (expected) BUT Python 2.7 PATH being inserted before the original system PATH.
Still if I look at the command line, it seems that Python 2.5 was executed.
Where is the first record in PATH (C:\Ptyhon27\) comming from, I can assure you this is added when the scripts runs, but by whom?
As you already observed I do have several versions of Python in PATH, this is not something anormal, because they can also have versioned executables instead and because Windows always picks the first one it the PATH.
Looking closely, it seems you have various versions of Python in your PATH environment variable.
The standard Python installer for Windows doesn't add itself to the PATH; I always do this manually for the version of Python I want to use by default. If you're using a different Python installer (such as ActiveState or Enthought) that may be the cause, but I haven't tried those.
In any case, you can edit your PATH environment variable manually and clean it up, leaving only the path to the version of Python you wish to be the default, as described here (scroll down a bit to get to the relevant section).
You might be interested in the Python Launcher for Windows project, a.k.a. PEP 397. Install it, and remove all Python dirs from PATH, leaving only the launcher one, and use py/pyw instead of python/pythonw.
Ahh, I think I have it! You didn't mention exactly how you're running Python...
Python adds the directory from which the command is run to the PATH! If you run it from the command line, this will be the directory in which the Python file you execute is located, or the directory you ran Python from if you just opened an interpreter. However, various tools, interpreters and development environments start up differently, and some of them will use a certain Python interpreter (depends on their configuration) and add its location to PATH.
If you want more help, please give a detailed description of how you're running Python when this happens.
I have some small utility scripts written in Python that I want to be usable on both Windows and Linux. I want to avoid having to explicitly invoke the Python interpreter. Is there an easy way to point shebang notation to the correct locations on both Windows and Linux? If not, is there another way to allow implicit invocation of the Python interpreter on both Windows and Linux without having to modify the script when transferring between operating systems?
Edit: The shebang support on Windows is provided Cygwin, but I want to use the native Windows Python interpreter on Windows, not the Cygwin one.
Edit # 2: It appears that shebang notation overrides file associations in Cygwin terminals. I guess I could just uninstall Cygwin Python and symlink /usr/bin/python to Windows-native Python.
Read up on the Python Launcher for Windows in the docs, which was initially described in PEP 397. It lets
you define custom shebang configurations in "py.ini" (e.g. to use pypy),
and out of the box you can use virtual shebangs such as #!/usr/bin/env python3, or shebangs with real paths such as #!"C:\Python33\python.exe". (Quoting is required for paths containing spaces.) You can also add command-line options to a shebang. For example, the following shebang adds the option to enter interactive mode after the script terminates: #!/usr/bin/python3 -i.
The installer associates .py (console) and .pyw (GUI) script file types with the respectively named launchers, py.exe and pyw.exe, in order to enable shebang support for scripts in Windows. For an all-users installation, the launchers are installed to the Windows folder (i.e. %SystemRoot%). For a per-user installation, you may need to manually add the installation directory to PATH in order to use py.exe in the shell (*). Then from the command line you can run Python via py -2, py -3, py -2.6, py -3.3-32 (32-bit), and so on. The launcher is handy when combined with -m to run a module as a script using a particular version of the interpreter, e.g. py -3 -m pip install.
(*) The new installer in 3.5+ defaults to "%LocalAppData%\Programs\Python\Launcher" for a per-user installation of the launcher, instead of installing it beside "python.exe", and it automatically adds this directory to PATH.
Unless you are using cygwin, windows has no shebang support. However, when you install python, it add as file association for .py files. If you put just the name of your script on the command line, or double click it in windows explorer, then it will run through python.
What I do is include a #!/usr/bin/env python shebang in my scripts. This allows for shebang support on linux. If you run it on a windows machine with python installed, then the file association should be there, and it will run as well.
Short answer:
The easiest way is to install git for windows wich comes with GitBash. Then add shebang lines in your scripts to indicate they should be run with python when executed.
#!/usr/bin/env python
More info:
Unlike Cygwin, git bash uses your native windows applications and lets you use bash scripts without any configuration.
It will automatically treat any file with a shebang line as executable the same way Linux shells do.
eg: #!/usr/bin/env php or #!/usr/bin/env node or any other application you want will work as long as you add the paths to your windows ENV path.
You can edit env vars in windows by hitting start and typing env should be the first option.
Git bash also installs git and hooks it up with a credentials manager for you and makes it super easy to sign into 2fa-enabled svn services and a ton of other handy developer features.
Git bash is IMO a must on every developer's machine.
Another option:
Install WSL (Windows Subsystem for Linux) which will work the same.
WSL also lets you install native Linux versions of all your command line applications if you prefer.
Linux binaries will take precedence over windows ones if installed but you can still choose to run the windows version of commands any time you want by specifically adding .exe on the end.
Install pywin32. One of the nice thing is it setups the file association of *.py to the python interpreter.
sorry for open old topic.
I create one file py.cmd and place it in the C:\Windows\System32 folder
py.bat:
#(
#set /p shebang=
)<%1
#set shebang=%shebang:#! =%
#%shebang% %1 %2 %3 %4 %5 %6 %7 %8 %9
py.bat file explain:
Get the first line from *.py file
Remove shebang characters "#! "
Run python file using shebang python path
All windows python script must start with shebang line as the first line in the code:
#! c:\Python27\python.exe
or
#! c:\Python37\python.exe
Then run it:
cmd> py SomePyFile.py param1 param1 paramX
Not with shebang ... but you might be able to set up a file association, see this SO question which deals with Perl and the associated answers which will also be pertinent as there's known problems with Windows and stdin/out redirection...