So i am running into a problem using subprocess.call() and i think i may just be calling it wrong. I am using:
subprocess.call('testingosfile.py')
and i get the traceback:
Traceback (most recent call last):
File "<pyshell#14>", line 1, in <module>
subprocess.call('testingosfile.py')
File "C:\Python27\lib\subprocess.py", line 493, in call
return Popen(*popenargs, **kwargs).wait()
File "C:\Python27\lib\subprocess.py", line 679, in __init__
errread, errwrite)
File "C:\Python27\lib\subprocess.py", line 893, in _execute_child
startupinfo)
WindowsError: [Error 193] %1 is not a valid Win32 application
and the contents of testingosfile.py is:
print "hello world!"
raw_input('....')
how do i manage to get this running?
Thank you in advance for your replies.
The error message makes perfect sense - with subprocess, you can only start an executable. So, to fix it, you should start an executable. Specifically, you should start the Python interpreter and tell it to run your script. Something like
subprocess.call(['python.exe', 'testingosfile.py'])
should work, although you might have to provide the full path to the Python interpreter (I can't test at the moment).
However, have you considered importing testingosfile.py instead? Whenever you import a Python script, all the commands in that script are run. Using
import testingosfile
inside a function in order to execute the commands would be poor style, but you could package up the useful commands of testingosfile.py into some function. Then, you could use
import testingosfile
at the top of your main script, and just call that function whenever you want to print Hello World and get the user's input.
try subprocess.call("myfile.ext", shell=True)
Related
Big picture is I'm trying to automate my deployment process of building with maven and deploying to a web logic server. Little picture is I'm using subprocess to see if I can call maven from within python. When I attempt this subprocess mistakes mvn for a file.
Here is my code so far:
import subprocess
def main():
print(subprocess.check_output(["mvn", "-v"]))
if __name__ == '__main__':
main()
And here's my error:
C:\pythondev\python.exe "C:/pythondev/development/deployment scripts/redploy-to-localhost.py"
Traceback (most recent call last):
File "C:/pythondev/development/deployment scripts/redploy-to-localhost.py", line 9, in <module>
main()
File "C:/pythondev/development/deployment scripts/redploy-to-localhost.py", line 5, in main
subprocess.check_output(["a"])
File "C:\pythondev\lib\subprocess.py", line 376, in check_output
**kwargs).stdout
File "C:\pythondev\lib\subprocess.py", line 453, in run
with Popen(*popenargs, **kwargs) as process:
File "C:\pythondev\lib\subprocess.py", line 756, in __init__
restore_signals, start_new_session)
File "C:\pythondev\lib\subprocess.py", line 1155, in _execute_child
startupinfo)
FileNotFoundError: [WinError 2] The system cannot find the file specified
Process finished with exit code 1
Although my issue is with subprocess I'm open to answers that suggest a better alternative.
I ran into the same issue and was hesistant to use shell=True, because the internet tells me this is evil.
When I run where mvn in my cmd.exe, I can see that there are two matches:
mvn, which is a Unix shell-script (it starts with #!/bin/sh),
mvn.cmd, which is a Windows batch file.
I think what happens when you execute mvn something -something in cmd.exe is the following: Windows tries finding an executable called mvn. It finds the mvn file, but realizes that this file is not executable. It then tries finding files like mvn.com, mvn.exe, ... (see the %PATHEXT% system variable). When it finds mvn.cmd, it executes that and everyone is happy.
As far as I understand it, the problem with subprocess.check_output (and subprocess.run, and so on) is that the path-"expansion" via %PATHEXT% is not being performed. So the solution is that you have to give the extension manually and run your command as
print(subprocess.check_output(["mvn.cmd", "-v"]))
Try this it worked for me.
print(subprocess.check_output(["mvn", "-v"], shell=True))
I can't run the wonderful PypeR (r to python interface) anymore.
I can import it, but as I try to run it it crashes.
I suspect it is because I installed El Capitan OSX.
I tried to install update pypeR with no success.
when I run it with:
e.g.
r = R()
that's the error that I get.
Traceback (most recent call last):
File "<pyshell#3>", line 1, in <module>
a = R()
File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/pyper.py", line 600, in __init__
self.__dict__['prog'] = Popen(RCMD, stdin=PIPE, stdout=PIPE, stderr=return_err and _STDOUT or childstderr, startupinfo=info)
File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/subprocess.py", line 710, in __init__
errread, errwrite)
File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/subprocess.py", line 1335, in _execute_child
raise child_exception
OSError: [Errno 2] No such file or directory
does anyone have a clue on how to solve this problem?
update:
if I run it from a shell instead of Idle it works.
I really can't see why.
Python's version is exactly the same, built at the same time.
It looks like PypeR cannot find R to run. Most likely the R command is not in the search path for command ($PATH) when you are using idle. One way is to explicitly point out which R command to use, e.g., if the R command is located in /usr/local/bin, you may use
r = R(RCMD="/usr/local/bin/R")
Of course, it is best if you can add R's path for idle environment.
I have an executable file that I'd like to run from Python. I define a path variable pointing at it:
>>> path = '/root/Cognos/Cognos/linuxi38664h/issetupnx'
I verify that I am in fact pointing at a file and not a directory:
>>> from os.path import isdir, isfile
>>> isdir(path)
False
>>> isfile(path)
True
But as soon as I try to run the executable file via subprocess.call...
>>> from subprocess import call
>>> call([path])
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/usr/lib64/python2.7/subprocess.py", line 524, in call
return Popen(*popenargs, **kwargs).wait()
File "/usr/lib64/python2.7/subprocess.py", line 711, in __init__
errread, errwrite)
File "/usr/lib64/python2.7/subprocess.py", line 1308, in _execute_child
raise child_exception
OSError: [Errno 2] No such file or directory
It tells me the file doesn't exist now.
The only possibility I can think of is that maybe the executable itself is being found and run fine, but the executable is failing saying that something it needs (what?) isn't found. I'm not sure how I would test this theory, though... or even if it's possible.
Another possibility might be some kind of permissions issue? Although I can't think of why I would have proper permissions to see the file but then I suddenly wouldn't be able to see it the moment I try running it.
Instead of using call, I should have used check_output. Then the error would have included all of the messages printed to stdout and stderr.
path = '/root/Cognos/Cognos/linuxi38664h/issetupnx'
from subprocess import check_output
check_output([path])
Then I would have gotten a more detailed message about how it failed to load shared libraries.
execute this code as root:
import subprocess as sp
path = '/root/Cognos/Cognos/linuxi38664h/issetupnx'
proc = sp.Popen([path],stdin=sp.PIPE)
proc.communicate()
This is my code so far
from subprocess import call
call("/Users/oscar/Desktop/Controlled Assessment/Currency Converter.py")
When I run it I get this error message
Traceback (most recent call last):
File "/Users/oscar/Desktop/Controlled Assessment/ISBN Checker.py", line 10, in <module>
call("/Users/oscar/Desktop/Controlled Assessment/Currency Converter.py")
File "/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/subprocess.py", line 470, in call
return Popen(*popenargs, **kwargs).wait()
File "/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/subprocess.py", line 744, in __init__
restore_signals, start_new_session)
File "/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/subprocess.py", line 1394, in _execute_child
raise child_exception_type(errno_num, err_msg)
OSError: [Errno 8] Exec format error
Since it looks like you're trying to execute another Python script, why not import it?
import Currency_Converter
And then run the modules you want in there? Take the space out of the file name and replace it with an underscore.
Check the interpreter directive from your script.
It should start with:
#!/usr/bin/env python
print 'your python script...'
That means that when you call this script directly, it will be interpreted by python binary.
You can get more info on http://en.wikipedia.org/wiki/Shebang_(Unix)
use subprocess.Popen
import sys, subprocess
subprocess.Popen([sys.executable, "myscript.py"])
This should run myscript.py within the Python command line.
Here's my copy.py:
from subprocess import call
call("copy p2.txt p3.txt")
If in command prompt I use
copy p2.txt p3.txt it copies fine.
but when I use python copy.py it gives me:
Traceback (most recent call last):
File "copy.py", line 2, in <module>
call("copy p2.txt p3.txt")
File "C:\Python27\lib\subprocess.py", line 493, in call
return Popen(*popenargs, **kwargs).wait()
File "C:\Python27\lib\subprocess.py", line 679, in __init__
errread, errwrite)
File "C:\Python27\lib\subprocess.py", line 896, in _execute_child
startupinfo)
WindowsError: [Error 2] The system cannot find the file specified
If I replace the python call to copy with xcopy, it works fine.
Why would this be?
When subprocess.call()ing a command like in a shell, you'll need to specify shell=True as well.
from subprocess import call
call("copy p2.txt p3.txt", shell=True)
The reason you need to use shell=True in this case is that the copy command in Windows is not actually an executable but a built-in command of the shell (if memory serves right). xcopy on the other hand is a real executable (in %WINDIR%\System32, which is usually in the %PATH%), so it can be called outside of a cmd.exe shell.
In this particular instance, shutil.copy or shutil.copy2 might be viable alternatives.
Please note that using shell=True can lead to security hazards, or as the docs put it:
Warning: Using shell=True can be a security hazard. See the warning under Frequently Used Arguments for details.