I'm trying to run a python script from a python program by kicking it off from subprocess (The reason is that the main program has to have exited when the script runs, with a combination of wx.CallAfter and Close). However when the script runs I get an error on line 1 with ImportError: No module named os which makes me think it's something to do with the PythonPath, but I can run the script just fine from a terminal.
Why can't the script see any core modules when run this way?
Edit:
The line in question is:
wx.CallAfter(subprocess.Popen,'python %s "%s" %s %s'%(os.path.join(BASE_DIR,"updatecopy.py"),BASE_DIR,pos[0],pos[1]),shell=True)
BASE_DIR is just the directory that the script lives in.
subprocess is there because os.exec* has been deprecated so I wouldn't suggest using that in place of Popen as someone suggested.
I've seen this issue crop up when running from a frozen process. If that is the case then you're most likely inheriting a weird environment for the new python process.
Most frozen scripts will be trying to run from a zip file, in which case it's no wonder that Python can't find anything, it's all trapped in a zip file :)
If this is the situation then try running using the python executable that you are using to run the frozen script. It should be able to deal with the special environment.
Maybe you could use os.execv instead of Popen.
From os/python docs:
These functions all execute a new program, replacing the current process; they do not return. On Unix, the new executable is loaded into the current process, and will have the same process id as the caller. Errors will be reported as OSError exceptions.
(emphasis mine)
Related
I compiled my python application using pyinstaller and the exe works fine, but when I run it on a different machine without python any part of the code which contains subprocess.Popen()doesn't run.
I read too many questions but I couldn't wrap my head around this.
My popen line:
try:
process = subprocess.Popen(['python', os.path.abspath('about.py')],stdout=subprocess.PIPE,stderr=subprocess.PIPE,stdin=subprocess.PIPE,
shell=True)
except Exception as e:
print(e)
Note that the executable runs on the host machine, but on another machines it runs but fails when launching the popen.
===UPDATE====
The console shows nothing and doesn't print an exception, so I guess this is a problem with python not being found. How can I fix this?
===UPDATE2====
Following the suggestion of viilpe I used "exec(open..." but it required me to import the about.py module first; importing the module runs it on top of the main module.
Putting exec(open...) inside the try\except runs the main module and the about module alongside each other; ruining the application's GUI.
I'm using "kivy" as my GUI library.
Looks like you want to execute about.py but there is no python.exe in pyinstaller bundle.
As advised here you can do it this way:
exec(open('about.py').read())
The whole point of PyInstaller is to make the destination computer be able to run your script without having a standalone python installation. You can't run a subprocess on a tool which isn't (necessarily) installed.
There are various ways to run Python as a subprocess of itself natively; start by exploring the multiprocessing library.
If the requirement to run Python twice is not a hard one, the absolutely simplest solution is to import about and run the code as part of your script. This probably requires some refactoring of the code in about.py.
I'm getting an interesting problem and I can't determine whether it's a problem with my code or the executable that I'm running. Basically I have a Python program that needs to call an external executable to process some data. If I call the executable via PowerShell or cmd, it works fine. However, if I attempt to run the executable via os.system() or subprocess.run(), I get the following error:
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
From my understanding of googling the issue, it would appear that this is some sort of C++-related issue, which is the language of the .exe that I'm running. I reinstalled the latest Visual C++ Redist and that did not seem to affect the problem. I've also tried to create a .bat and .ps1 script that runs the .exe. These both run fine via PowerShell and CMD, but raise the same error when run via os.system() and subprocess.run(). The error message is rather nondescript so I'm wondering if anyone knows anything about it and why os.system() etc. might be throwing it.
The relevant code is simply
os.system("GaussBin.exe gaussInput.txt gaussOutput.txt")
When the string is pasted into cmd, it runs perfectly. Additionally, if the parameters of the system() call are incorrect, the exe properly displays the usage function. It's only when I add the output.txt and the program is supposed to run fully that things start to break.
I've had some confusion about what directory os.system runs in. Should I be using .\ when calling the exe?
The .exe file is provided, not built by me.
Recently, I came across the Linux command source and then found this answer on what it does.
My understanding was that source executes the file that is passed to it, and it did work for a simple shell script. Then I tried using source on a Python script–but it did not work.
The Python script has a shebang (e.g. #!/usr/bin/python) and I am able to do a ./python.py, as the script has executable permission. If that is possible, source python.py should also be possible, right? The only difference is ./ executes in a new shell and source executes in the current shell. Why is it not working on a .py script? Am I missing something here?
You're still not quite on-target understanding what source does.
source does indeed execute commands from a file in the current shell process. It does this effectively as if you had typed them directly into your current shell.
The reason this is necessary is because when you run a shell script without sourcing it, it will spawn a subshell—a new process. When this process exits, any changes made within that script are lost as you return to the shell from which it spawned.
It follows, then, that you cannot source Python into a shell, because the Python interpreter is always a different process from your shell. Running a Python script spawns a brand-new process, and when that process exits, its state is lost.
Of course, if your shell is actually Python (which I would not recommend!), you can still "source" into it—by using import.
source executes the files and places whatever functions/aliases/environment variables created in that script within the shell that called it. It does this by not spawning a new process, but instead executing the script in the current process.
The shabang is used by the shell to indicate what to use to spawn the new process, so for source it is ignored, and the file is interpreted as the language of the current process (bash in this case). This is why using source on a python file failed for you.
I have a python script that runs well. It invokes another scripts like this:
os.system('python creep.py '+ str(time)+' ' +str(date) +' '+name_sample)
How can I step into the script "creep.py" when I debug it with pdb?
You can't. That script is running in a separate process. pdb doesn't have any special capability to recognize executables as Python interpreters and "attach" to scripts they may be running.
You shouldn't be shelling out to run another script though... better to just import it and call its methods directly.
I agree with kindall that it is a good idea to try importing the other script and calling its methods directly. This will hopefully get rid of your problem, and also it will be easier to trace errors while debugging in the future.
The story began with a very strange error while I was running my script from PyDev. Running the same script from outside will not encounter the same problem.
Fatal Python error: Py_Initialize: can't initialize sys standard streams
File "C:\Python26\lib\encodings\__init__.py", line 123
raise CodecRegistryError,\
^
SyntaxError: invalid syntax
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
I was able to find why this is happening: In PyDev I use two different Python versions: 3.1 that is the default installation and 2.6 as the alternative one.
My Windows Environment does not contains PYTHONHOME, CLASSPATH, PYTHONPATH but PyDev does add them.
Now the problem is at one stage my python script does execute another python script using os.system(python second.py) and the second script will fail with the above error.
Now I'm looking to find a way to prevent this issue, issue that is happening because it will run the execute the default python using the settings for the non-default one (added by PyDev).
I do not want to change the standard call (python file.py) but I want to be able to run my script from pydev without problem and being able to use default or alternative python environment.
Any ideas?
I found a solution that seams acceptable specially because it will not interfere with running the scripts on other systems, just to run python -E second.py - this will force Python to ignore PYTHON* environment variables.
I may not be understanding this quite right, but I think you're invoking a script from pydev that works okay, but this script executes another script which requires a different version.
While this would unfortunately be installation-specific, you could use os.system("c:\absolute\path\to\proper\version\of\python.exe second.py").
If PyDev is setting up conflicting environmental variables, you may want to look into subprocess over os.system.
http://docs.python.org/library/subprocess.html#using-the-subprocess-module
This will allow you to invoke a process with a handle, so you can optionally wait for it to terminate. It will also allow you to pass environment variables upon execution.
I believe your call should be:
import sys
os.system(sys.executable+ ' second.py')
So that you guarantee you're using the same interpreter you're currently running and not launching the other one (or did you really mean to use the other interpreter?)