1

Short answer: If absence of input() in the end of the file is not the case, then double-tripple-quadripple check what version of Python is trying to run your script when double-clicked from explorer. To do so put import pdb; pdb.set_trace() somewhere up in the script, double-click it, and look at the header of the window.

The question is in the header. I've written a simple python app which works well if i run it from Iddle and if i run it from command line by "python foo.py" (using Windows 10).

However it doesn't work if run by double-clicking in win. explorer. Command line window pops up, flashes - and it's gone. I managed to conclude that commenting out these imports:

from pysvn import Client
from urllib import parse

prevents whatever bad happens from happening, and app can run, but i need those imports.

What could possibly cause this? I am sure that file assosiation is set correctly and double clicking causes C:\Python\Python 3.5.3\python.exe to open .py files. What's the difference between running .py from command line and running them from win. explorer?

Edit 1: i did try to create a bat file with this line in it: "C:\Python\Python 3.5.3\python.exe" foo.py %* - and it works just fine. However, a shortcut to cmd.exe made as said here doesn't work.

Edit 2: @Mark Mikofski comment helped me to notice that even though i thought double-clicking causes C:\Python\Python 3.5.3\python.exe to open .py files - process name showed it was python2.7. Even when i right-click my foo.py file and manually open it with python.exe from Python 3.5 folder. This is a mystery for me, but uninstalling python 2.7 helped to solve the issue, so now i know i should search on how to make different versions of python run together smoothly and/or how to tell a script to use a specific version (shebang doesn't seem to work on windows)

Community
  • 1
  • 1
alexpad
  • 133
  • 5
  • The cwd-folder (from which python is executed) might be different and this matters especially when using relative paths (as the environment-variables are different; this is a common problem with chron + python). (But i never played around with that kind of stuff). – sascha May 14 '17 at 15:25
  • @sascha, so, you're saying, that environment-variables are different when i open command line by myself, and when it opens as the result of double-clicking .py file? That could cause my problem. How do i check this? Or where to look for more info? – alexpad May 14 '17 at 15:38
  • You could try to tease out whether this is the problem by creating a shortcut to the Windows command prompt, which would then in turn run Python with your script. See this on how to set that up: http://stackoverflow.com/questions/9738434/run-a-command-prompt-command-from-desktop-shortcut – Abid Hasan May 14 '17 at 17:13
  • @Abid Hasan, forgot to mention, i did create a bat file with this line in it: `"C:\Python\Python 3.5.3\python.exe" foo.py %*` - and it works just fine. However, a shortcut to cmd.exe made as said [here](http://stackoverflow.com/questions/9738434/run-a-command-prompt-command-from-desktop-shortcut/25817258#25817258) doesn't work. – alexpad May 15 '17 at 06:39
  • try putting [`import pdb; pdb.set_trace()`](https://docs.python.org/2/library/pdb.html) somewhere in your `foo.py` file to stop it from executing and give you a debugger prompt. then you can `import os` and check [`os.getcwd()`](https://docs.python.org/2/library/os.html#os.getegid) and figure what the problem is. – Mark Mikofski May 15 '17 at 06:51
  • @Mark Mikofski, I've put `import pdb; pdb.set_trace()` in my file and (cwd were the same, btw) noticed, that my file is in fact opened in python2.7 rather than in python3 when double-clicked. This is completely unexpecting, moreover this is still the case even when i right click the file -> open with -> navigate to python.exe in python 3.5 folder. And python 2.7 doesn't have all the libraries required so it's not working. – alexpad May 15 '17 at 07:38
  • Maybe you should change the title of your question? – Mark Mikofski May 15 '17 at 08:07
  • @Mark Mikofski, `pdb.set_trace()` forced the window to stay open, and the header of the window was the path to python.exe from Python 2.7 folder. – alexpad May 15 '17 at 08:13

1 Answers1

0

However it doesn't work if run by double-clicking in win. explorer. Command line window pops up, flashes - and it's gone.

This is normal under Windows, you need to put input at the end of your script if you want the Command Prompt window to stay until you hit enter key. Once your console program executes and reaches the end-of-file where you have nothing left, it just exits, this is by default under Windows.

What could possibly cause this? I am sure that file association is set correctly and double clicking causes C:\Python\Python 3.5.3\python.exe to open .py files. What's the difference between running .py from command line and running them from win. explorer?

*If you have Python Windows Launcher installed in your Windows machine, clicking on files will run py.exe and this executable will determine the right python.exe to run your script with, except if you changed the file association from Windows to run python.exe directly or if you've chosen not to install the launcher all together. The big difference is that, Windows File Explorer may or may not run python.exe, you have to double check that in Windows, while in Command Prompt when you type: python.exe myscript.py executes myscript.py with python.exe. Typically Windows will find python.exe from the environment variable PATH.

Try to click on this script and see what happens:

#myscript.py
input("Press enter to exit")

The console window should stay when you click on this script file.

GIZ
  • 4,409
  • 1
  • 24
  • 43
  • Thanks for the answer. Sorry i didn't mention this earlier - i, of course, have already put `input()` in the end of the file, so this is not the case. I've got some new info and will update my question soon. – alexpad May 15 '17 at 07:43
  • @alexpad In your Edit 2 you mentioned shebang doesn't work in Windows. You should then install Windows Python Launcher to parse shebangs. Try to run the above code I provided as an isolated case to see if this behavior is limited to your script or all scripts in your machine. – GIZ May 15 '17 at 08:27