I am using:
Windows XP
Python 2.6.2 (standard install from python.org)
git version 1.6.5.1-preview20091022 (installed from http://code.google.com/p/msysgit/)
I have an environment variable looking like an absolute path (/path/to/dir) but I'm using it to construct a git URL. At some point, it's getting translated to C:/Program Files/Git/path/to/dir. It seems like Python is at fault:
In a git bash shell:
$ export VAR=/path/to/dir
$ echo $VAR
/path/to/dir
$ python
>>> import os
>>> os.environ['VAR']
'C:/Program Files/Git/path/to/dir'
git bash is not translating the path, but Python is?
In a Windows Command Prompt, Python gets it right:
C:\>set VAR=/path/to/dir
C:\>echo %VAR%
/path/to/dir
C:\>python
>>> import os
>>> os.environ['VAR']
'/path/to/dir'
Can anyone explain what's going on here? And how can I prevent the translation in a bash shell?
EDIT: I should add that my python script runs on OS X and Windows, so if anyone does have a solution it would be good if worked on both platforms.
The problem definitely sounds like it's caused by MSYS. When an MSYS process execs a non-MSYS process (e.g. your msysgit bash shell calling native Windows Python), the arguments are checked for anything that looks like an absolute POSIX path (e.g. things that start with a single '/') and these are translated to the underlying 'real' Windows path so that the non-MSYS program can find them. It's likely that this same process happens to the contents of your environment variables too, for the same reason.
This would be why removing the leading '/' works (the value doesn't look like a POSIX path any more), why adding an extra one works (ditto), and why this works fine under Cygwin (it's not MSYS). I'm also guessing that you installed msysgit at 'C:\Program Files\Git', and that this is why MSYS thinks its 'fake' POSIX file hierarchy is rooted there and adds it to the front of '/path/to/dir' for you.
Unfortunately, if that is the explanation then there isn't a clear solution. I hit a similar issue trying to pass remote paths through ssh and haven't found any good ways round this myself, and according to the discussion at http://comments.gmane.org/gmane.comp.gnu.mingw.msys/4511 (from 2008) there simply isn't an obvious fix beyond the workarounds you've found so far. If this turns into a bigger problem for you, you might want to raise it on the MinGW-MSYS mailing lists or bug tracker. According to the Gmane discussion, it had never been reported formally despite being a known issue.
My guess would be that this is not python at fault, but the git bash shell.
Maybe the git bash shell is lying to you when you look at the variable.
Or, try to not put the first / and add it again later (if translation does not occurs).
If I try with cygwin, it works:
$ export test="/bin"
$ python
>>> import os
>>> os.environ["test"]
'/bin'
The console you get from msysgit is probably modified for git user's needs, from my POV, it is only useful for simple tasks and to access git command line not to develop and run python scripts (you are using a Python installation for Windows in a shell installed for a specific application, that doesn't sound good).
You should install Cygwin and his python package (and even git package if you want) to get a correct POSIX environment with binaries and libraries prepared for it.
Related
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.
No, Windows does not support shebang lines.
The documentation you've linked relates to the py launcher installed by Python, which can interpret various shebang lines to choose a Python version to run a script with.
setuptools is able to generate wrapper .exes for your Python scripts, but it gets a little involved and already assumes you have a package with a setup.py and so on.
Locally, if you really, really need this, you probably could add .py to the PATHEXT environment variable, so the Windows command line looks up .pys like it looks up .exes (and various others; the current modern default is .COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC). However, this will naturally not scale for distributing apps, as all of your users would need to set that too.
My recommendation is to stick with just that boring old python testing.py, really.
You can use shebang in windows by setting the path of your interpreter as the first line in the file(you will see a marker on VSCode that says 'set as interpreter ' on that line).
Using windows 10,Python version 3.9 see example:
#!C:/Users/waithira/AppData/Local/Programs/Python/Python39/python.exe
print('hello world')
if you're not going to do this often. You can still add a batch file to your path testing.bat containing the command that you need to execute your code.
#echo off
python testing.py
It's a borring workaround but it works without needing to mention the extention since windows interpret batch files the same way it interpret executables.
I have several packages on my windows python environment and I would like to use them inside Cygwin. Can I setup a virtual environment linked to the files used for the windows' python or do I have to copy the files?
Older Cygwin was written with its stdin, stdout, stderr bound to Windows i.e. it was a Win32 console program. Then it was possible to run Windows version of Python as:
/cygdrive/c/Python27/python.exe
You could even have added /cygdrive/.../Pythonxx to your path variable.
Newer versions are written with implemented their own terminals and when you run an Win32 console app like Python it freezes.
Even running it under "cmd" run inside cygwin won't work.
Half an answer is to run it always in interactive mode, then it works a little. Eg.
/cygdrive/c/Python27/python.exe -i program.py
or just for shell
/cygdrive/c/Python27/python.exe -i
You can try playing around under cygwins options, and change a terminal which it currently emulates, to see whether it will do you any good.
Running Windows version of Python under cygwin, if you have older one, will be like you are still in Windows but using Unix console.
I think that is not something you would like to do anyway,
but mentioned it just in case.
I would like to do just that very much, but well, on newer Cygwins it doesn't work.
Then all modules are still there. And you're still in Cygwin.
To access modules which are in Windows version of Python from Cygwins version you add the Windows site-packages to the Python path variable.
On top of your program do:
import sys
sys.path.insert(0, "/cygdrive/c/Python27/lib/site-packages")
Then you can import them normally. But, this isn't exactly advisable.
For example, all modules that depend on windows paths could have great problems.
Or those written in C wouldn't exactly like been called from Cygwin.
Especially when Cygwin's Python version number and Windows's one aren't the same.
I tried with pyaudio, it collosaly crashed.
Some of them (mostly the little ones) will work just fine.
But, IMPORTANT NOTE here is, depending on the place you insert your Windows site-packages path the directory will be searched.
If you put it in place 0, Python will look at it firstly.
Then, it is perhaps better to use:
sys.path.append("/cygdrive/c/Python27/lib/site-packages")
If some package is packed into an EGG or ZIP archive, you will have to add it separately to the path.
The same goes for subdirectories. You try and keep thumbs up.
If you don't want to do that, you can:
import os
wd = os.getcwd()
os.chdir("/cygdrive/c/Python27/lib/site-packages")
# Your Windows imports here
os.chdir(wd)
Sometimes you will have to do both.
You can add even a check, so that your program works in both environments nicely:
if sys.platform=="cygwin": ...
It will work without a check, but it is stupid to bother Python with twice added same directory into the path.
Copying the packages will save you from these extra lines of code, but the problems I mentioned above will remain the same.
Never the less, if the modules are small, copy them, if not, do as I said, but be aware that it's not exactly something that is supposed to be done.
I can TAB-complete current open file variables, paths & globals, but my python subclasses are not detected on TAB completion. For instance,
import os # os is built-in library.
os. # ycm does not complete members of this class.
It has been 48h that I'm searching the solution. My /usr/bin/python -> /usr/bin/python2.7, all the tests pass 100% and the build was successful.
> uname -r
4.0.5-1-ARCH
I tried installing packages specific to Arch Linux from repositories and they don't seem to work.
At this point, I think my best chance would be to find the place where the python path or a variable with this purpose is set in the original package for Vundle, YouCompleteMe. Then, I should be able to verify that it is correct. I am open to all possible solutions or insights on this issue.
> echo $PYTHONPATH
/usr/lib/python2.7/
Thank you for your time!
YouCompleteMe relies on Jedi-Vim for python completion.
I just found that it was due to an incomprehension error that I described for Jedi Vim here. However, with YouCompleteMe plug-in only few methods shows up on:
from os import getc
Then I pressed ctrl + space and a complete list of available modules was displayed.
Questions similar to this have been asked before, but I only can find explanations of the problem, not solutions.
I am running OS X Mavericks, and learning python. I installed Python but little did I know it was built in.
I use sublime text as my IDE, and I tried to install a few libraries (scipy, numpy, matplotlib). In Sublime Text, when I import the libraries, they work. I can import scipy and print scipy.pi perfectly. However, when I ran it in the terminal, it said it couldn't find those libraries.
Others have explained that the terminal is running the operating system's python and couldn't find the library, but didn't explain where one should place the libraries for it to run properly in the terminal.
Any help is appreciated, thank you
The short answer to your question is that you need to modify your PYTHONPATH environment variable to point to the modules that you want. If you're using bash (which you most likely are), you can do that like this:
export PYTHONPATH=$PYTHONPATH:'/path/to/your/modules/'
However, rather than running the OS X version of python, I would recommend that you run the python version that you installed. If you installed using the .dmg from python.org, you can probably just type 'python2.7' or 'python3' (depending on which version you installed) in the terminal and everything will just work.
If you want to, you can set the command 'python' to run the version of python that you installed rather than the OS X default python by putting in an alias or modifying your PATH environment variable in your ~/.bash_profile file. The easier option is to use the "Update Shell Profile" script that lives in the python folder after the installation.
One more possibility for you to mull over -- consider setting up a virtual environment with virtualenv, and installing scipy, numpy, etc. in there. This option might be more trouble than it's worth when you're first starting out, but in the long run it's a good skill to have and will make your development cleaner and easier to maintain.
Finally, since it sounds like you might be doing scientific computing, you could take a look at EPD free, which comes with many scientific packages preinstalled, and as a bonus will setup the necessary shell variables for you automatically.
You need to find out exactly what you are calling from Sublime Text. This solution ONLY applies if what others are saying is true and Sublime Text is calling another python interpreter that is different from the one that you are calling from the shell.
Step 1
Quick and dirty way to find out what Sublime Text is calling:
Make Python your build system. Select on menu bar: Tools > Build System > Python
Create new file (cmd+n)
Build (cmd+b)
This should give you an error message like this:
/usr/local/Cellar/python/2.7.5/Frameworks/Python.framework/Versions/2.7/Resources/Python.app/Contents/MacOS/Python: can't find '__main__' module in ''
[Finished in 0.1s with exit code 1]
[shell_cmd: python -u ""]
[dir: /Users/someuser/Downloads]
[path: /usr/bin:/bin:/usr/sbin:/sbin]
The first line is giving you the path to python interpreter that Sublime Text is using.
Step 2
Next, you should find out what you are calling in the command line:
% which python
/usr/local/bin/python
Using the information above, you can locate where /usr/local/bin/python is by:
% ls -la /usr/local/bin/python
lrwxr-xr-x 1 someuser wheel 33 Jul 29 23:14 /usr/local/bin/python# -> ../Cellar/python/2.7.5/bin/python
If that the two paths are the same, then stop: my solution will not apply to your situation.
Step 3
If the two paths are different, then you will need to either specifically use the path to the python interpreter that sublime text is calling:
% echo 'print "hello"' | /usr/local/Cellar/python/2.7.5/Frameworks/Python.framework/Versions/2.7/Resources/Python.app/Contents/MacOS/Python
hello
Or, if you like to just use python to call in command line, then you can change the link that came up by "which python" (e.g., /usr/local/bin).
e.g. (DO NOT COPY AND PASTE THIS - please understand where the paths came from and why):
ln -s PATH_TO_YOUR_PYTHON /usr/local/bin/python
For better discussion about changing default python on OSX, see "How to change which Python version gets used in Snow Leopard?".
Another thing - if you want to run different python from Sublime Text, then take a look at this.
My command prompt is currently running Python 3.2 by default how do I set it up to run Python 2.7 by default, I have changed the PATH variable to point towards Python 2.7, but that did not work.
UPDATE:
It still does not work. :(
Still running python3 - to be specific it runs python3 when I am trying to install flask - which is what I want to do.
More generally, when I simply type python into the command line, it does nothing.
I get a 'python' is not recognized as an internal or external command, operable program, or batch file error.
No idea what to do.
If you call your Python scripts directly using python script.py then setting the PATH to have the 2.7 directory first should be enough.
If you want to call Python scripts indirectly with the shell, i.e. by writing just script.py or by executing the file from the explorer, you need to set the 2.7 installation as the default program handler for the .py extension. The easiest way to do that is to run the Python installer again and choose the option “make this installation the default”.
Note that with the new launcher, that ships with 3.3+, you don’t need this, as you can specify the version number using a shebang line and the launcher will automatically pick the appropriate interpreter.
Changing your PATH environment variable should do the trick. Some troubleshooting tips:
Make sure you didn't just change the local, but rather the system variable to reflect the new location
Make sure you restarted your CL window (aka close "cmd" or command prompt and reopen it). This will refresh the system variables you just updated.
Make sure you remove all references to C:\Python32\ or whatever the old path was (again, check local and system PATH - they are both found on the same environmental variables window).
Check to see if Python3.2 is installed where you think it is... (just rename the directory to something like OLD_Python3.2 and go to your CLI and enter "python" - does it start up? If it does is it 2.7? or 3.2? If not, you did something wrong with your PATH variable.
All else fails - reboot and try again (you might have some persistent environment variable - which I don't see how that can be - but hey, we are brainstorming here! - and a reboot would give you a fresh start.
If that doesn't work then I'd think you are doing something else wrong (aka user error). CMD has to know where to look for python before it can execute. It knows this from your PATH variable... now granted, I work almost exclusively in 2.6/2.7, so if they did something to the registry (which I doubt) then I wouldn't know about that.
Good luck!
Change the two las lines to you current python desired build path:
Windows Registry Editor Version 5.00
' Extracted from Python 2.7 silent installation By Elektro H#cker
[HKEY_CLASSES_ROOT\.py]
#="Python.File"
[HKEY_CLASSES_ROOT\.pyc]
#="Python.CompiledFile"
[HKEY_CLASSES_ROOT\.pyo]
#="Python.CompiledFile"
[HKEY_CLASSES_ROOT\.pyw]
#="Python.NoConFile"
[HKEY_CLASSES_ROOT\Python.File\Shell\Open\Command]
#="CMD /K \"\"C:\\Program Files (x86)\\Python\\Python.exe\" \"%1\" %*\""
[HKEY_CLASSES_ROOT\Python.NoConFile\Shell\open\command]
#="CMD /K \"\"C:\\Program Files (x86)\\Python\\Pythonw.exe\" \"%1\" %*\""
Could you try this as root:
$ ln -s python2.7 /usr/local/bin/python
Logout & login again as root:
$ python -V
It works for me, hoping the same to you.
Cheers,