80

I am trying to call a Python file "hello.py" from within the python interpreter with subprocess. But I am unable to resolve this error. [Python 3.4.1].

import subprocess    
subprocess.call(['hello.py', 'htmlfilename.htm'])
Traceback (most recent call last):
  File "<pyshell#42>", line 1, in <module>
    subprocess.call(['hello.py', 'htmlfilename.htm'])
  File "C:\Python34\lib\subprocess.py", line 537, in call
    with Popen(*popenargs, **kwargs) as p:
  File "C:\Python34\lib\subprocess.py", line 858, in __init__
    restore_signals, start_new_session)
  File "C:\Python34\lib\subprocess.py", line 1111, in _execute_child
    startupinfo)
OSError: [WinError 193] %1 is not a valid Win32 application

Also is there any alternate way to "call a python script with arguments" other than using subprocess?

bad_coder
  • 11,289
  • 20
  • 44
  • 72
Caxton
  • 1,050
  • 1
  • 8
  • 10
  • 1
    Same error but slightly different cause: [\[SO\]: Python Ctypes - loading dll throws OSError: \[WinError 193\] %1 is not a valid Win32 application](https://stackoverflow.com/q/57187566/4788546). – CristiFati Feb 05 '23 at 15:07

14 Answers14

57

The error is pretty clear. The file hello.py is not an executable file. You need to specify the executable:

subprocess.call(['python.exe', 'hello.py', 'htmlfilename.htm'])

You'll need python.exe to be visible on the search path, or you could pass the full path to the executable file that is running the calling script:

import sys
subprocess.call([sys.executable, 'hello.py', 'htmlfilename.htm'])
David Heffernan
  • 601,492
  • 42
  • 1,072
  • 1,490
  • 367
    "The error is pretty clear." Today I learned there's a new meaning for the word "clear". – Ram Rachum Aug 08 '15 at 14:33
  • 39
    The error message is esp. *not* clear because it does not resolve `%1` to `hello.py` for some reason. IMO that's a bug in Python. – sschuberth Jan 07 '16 at 13:03
  • @sschuberth How would Python do that? It's not Python that encounters the error. It's the `subprocess` module. It would have to check the error code and supply a substitution string only for this specific error. I know of very few programs that do that. – David Heffernan Jan 07 '16 at 13:12
  • 7
    @david-heffernan I don't know enough about the implementation details of core Python / the subprocess module to say where the `%1` placeholder comes from, and why it's not resolved to a file name. But as you said, even if the bug was in the Windows API, and the error message always contains an unresolved `%1` placeholder, in case of an `OSError` `subprocess.call` could scan the error message for `%1` and replace it accordingly before feeding the message to the exception. – sschuberth Jan 07 '16 at 13:23
  • 2
    @david-heffernan Not that I would think this discussion is leading somewhere, but no, I do not necessarily need to know where exactly the `%1` comes from in order to know that Python is in a position to fix / improve it. And when I say "Python", that includes the subprocess module. – sschuberth Jan 07 '16 at 13:48
  • @sschuberth It's just hard to do comprehensively, for all possible error messages, for all API calls. Indeed, it's not always clear what value to put in %1. After all, it could be one of the loader resolved dependencies that leads to this failure. So the executable file could be valid, but `somelibrary.dll` may be invalid. And the caller of `CreateProcess` simply cannot know. In reality I'd say that Win32 is at fault for serving up these format strings that cannot viably be used. I don't know any program that replaces these strings. – David Heffernan Jan 07 '16 at 13:51
  • 3
    We're not complaining that Python didn't automagically fill in %1. We're complaining that you claim "the error is pretty clear" when you later say "it's not always clear what value to put in %1", and we all think the "not clear" statement is more realistic. If you had omitted your first sentence, or said "%1 should be hello.py, but Python can't fill it in for complicated reasons", none of this comment thread would have happened. – Teepeemm Jul 12 '18 at 13:12
  • 1
    @Teepeemm I don't agree. I think you've misunderstood various comments. The first comment, the one with all the votes, has nothing to the %1. That's a comment that asserts that "not a valid Win32 application" is unclear. It seems very clear to me, but perhaps that's because I'm experienced in Win32 and didn't see things from the perspective of those that aren't. Every comment after that concerns the %1 which is something of a red herring. That part isn't very clear for sure, but it's absolutely not a Python bug. It's just a design limitation of Windows error reporting. – David Heffernan Jul 12 '18 at 13:47
  • I am having the same error, but only the command 'import oct2py' is enough for me to encounter it. Any ideas why? – Wallflower Jan 20 '21 at 09:31
  • @Wallflower It's because oct2py is trying to loading a module that isn't valid, usually 32 bit vs 64 bit – David Heffernan Jan 20 '21 at 10:27
  • @David-Heffernan I have checked everything. Python installation 64 bits, octave 64bits... I don't know what else to check. My environment variables are correct. I have posted the question [here](https://stackoverflow.com/questions/65792257/problems-importing-the-oct2py-python-package?noredirect=1#comment116324813_65792257) yesterday and still haven't got an answer... – Wallflower Jan 20 '21 at 11:22
  • @DavidHeffernan Hello I have the same error while importing TensorFlow, how can I solve it? – MRUNAL MUNOT Feb 22 '21 at 13:10
  • @MRUNAL Depends on what is triggering the error – David Heffernan Feb 22 '21 at 13:20
  • @DavidHeffernan How can I solve? or which material should I refer as it is giving error as my file contains only import TensorFlow? – MRUNAL MUNOT Feb 22 '21 at 13:35
  • @MRUNALMUNOT https://www.google.com/search?q=tensorflow+%251+is+not+a+valid+Win32+application&oq=tensorflow+%251+is+not+a+valid+Win32+application – David Heffernan Feb 26 '21 at 12:11
20

Python installers usually register .py files with the system. If you run the shell explicitly, it works:

import subprocess
subprocess.call(['hello.py', 'htmlfilename.htm'], shell=True)
# --- or ----
subprocess.call('hello.py htmlfilename.htm', shell=True)

You can check your file associations on the command line with

C:\>assoc .py
.py=Python.File

C:\>ftype Python.File
Python.File="C:\Python27\python.exe" "%1" %*
tdelaney
  • 73,364
  • 6
  • 83
  • 116
  • 4
    Thanks for reminding me that `shell=True` is always an option for when `subprocess` is mysteriously failing! This question is unrelated to my issue (I have an actual Windows executable, it just won't run for some reason... doesn't matter if I use a 32 bit or 64 bit version of the interpreter), but your suggestion of using `shell=True` works! – ArtOfWarfare Jan 16 '17 at 16:18
15

I got the same error while I forgot to use shell=True in the subprocess.call.

subprocess.call('python modify_depth_images.py', shell=True)

Running External Command

To run an external command without interacting with it, such as one would do with os.system(), Use the call() function.

import subprocess

#Simple command 
subprocess.call(['ls', '-1'], shell=True)

Setting the shell argument to a true value causes subprocess to spawn an intermediate shell process, and tell it to run the command. The default is to run the command directly.

 import subprocess

 # Command with shell expansion
 subprocess.call('echo $HOME', shell=True)
Nate Anderson
  • 18,334
  • 18
  • 100
  • 135
Mona Jalal
  • 34,860
  • 64
  • 239
  • 408
9

All above solution are logical and I think covers the root cause, but for me, none of the above worked. Hence putting it here as may be helpful for others.

My environment was messed up. As you can see from the traceback, there are two python environments involved here:

  1. C:\Users\example\AppData\Roaming\Python\Python37
  2. C:\Users\example\Anaconda3

I cleaned up the path and just deleted all the files from C:\Users\example\AppData\Roaming\Python\Python37.

Then it worked like the charm.

This link helped me to found the solution.

bad_coder
  • 11,289
  • 20
  • 44
  • 72
Red Boy
  • 5,429
  • 3
  • 28
  • 41
2

My problem was involving poetry and argparse. I was calling the script with arguments like so:

poetry run .\src\script.py --help

and was getting this same errorr, so when I changed my command to:

poetry run python.exe .\src\script.py --help

then and all worked fine.

paradox
  • 634
  • 5
  • 13
2

I got this error while trying to install SpaCy. I had Python 3.7 32-bit version, which didn't let me install SpaCy.

First, I tried to upgrade to Python 3.9 64-bit version and uninstalled python 3.7. Then to save my libraries I copied the site-packages of the python 3.7 version to the 3.9 version, which gave me this error while downloading SpaCy.

While there were a lot of errors in the lib folder, but I solved [OSError: WinError 193] by uninstalling NumPy and then re-installing it.

bad_coder
  • 11,289
  • 20
  • 44
  • 72
Singh
  • 504
  • 4
  • 15
1

Uninstalling numpy from command line / terminal through pip fixed the error for me:

pip uninstall numpy

Greg Kramida
  • 4,064
  • 5
  • 30
  • 46
SaimumIslam27
  • 971
  • 1
  • 8
  • 14
1

For me issue got resolved after following steps:

  1. Installing python 32 bit version on windows.
  2. Add newly installed python and it's script folder(where pip resides in environment variable)

Issue comes when any application you want to run needs python 32 bit variants and you have 64 bit variant

Note : Once you install python 32 bit variant,dont forget to install all required packages using pip of this new python 32 bit variant

Adriaan
  • 17,741
  • 7
  • 42
  • 75
1

The file hello.py is not an executable file. You need to specify a file like python.exe

try following:

import sys
subprocess.call([sys.executable, 'hello.py', 'htmlfilename.htm'])
MRUNAL MUNOT
  • 395
  • 1
  • 5
  • 18
0

OSError: [WinError 193] %1 is not a valid Win32 application

This error is most probably due to this line import subprocess

I had the same issue and had solved it by uninstalling and reinstalling python and anaconda then i used jupyter and wrote pip install numpy this gave me the whole path where it was getting my site-packages from i deleted my site-packages folder and then the error dissappeared. Actually because i had 2 folders for site-packages one with anaconda and other somewhere in app data(which had some issues in it), since i deleted that site-package folder then it automatically started taking my libraries from site-package folder which was with anaconda hence the problem was solved.

0

For anyone experiencing this on windows after an update

What happened was that Windows Defender made some changes. Possibly cause running data extraction scripts, but python.exe got reduced to 0kb for that project. Copying the python.exe from another project and replacing it solved for now.

Robin T
  • 1
  • 1
  • 2
-1

I too faced same issue and following steps in resolution of this.

  1. I removed unnecessary python path from system except anaconda path.
  2. C:\Users<user-Name>\AppData\Roaming<python> = remove any unnecessary python files /folder. these files may interfere with current execution.

Regards Vj

vijay
  • 17
  • 2
-2

I solved this by Following steps:

  • 1 > Uninstalled python
  • 2 > removed Python37 Folder from C/program files/ and user/sukhendra/AppData
  • 3 > removed all python37 paths

then only Anaconda is remaining in my PC so opened Anaconda and then it's all working fine for me

-4

Delete all the python folders from

C:/program files/user/AppData/python

then it will work (if you have jupyter error).

Petr Javorik
  • 1,695
  • 19
  • 25
  • 1
    `C:/program files/user/AppData/python` doesn't look like a path that would exist. Do you mean `C:/Users/user/AppData/python`? – Donald Duck Nov 12 '21 at 17:44
  • 1
    Your answer could be improved with additional supporting information. Please [edit] to add further details, such as citations or documentation, so that others can confirm that your answer is correct. You can find more information on how to write good answers [in the help center](/help/how-to-answer). – targhs Nov 12 '21 at 18:24