Subprocess in maya being naughty

When using subprocess.call in one of my scripts I’m getting the following error, it is in a 32-bit win7 config running maya 2011:


# # Exception in thread Thread-2:
# Traceback (most recent call last):
# File "C:\Program Files (x86)\Autodesk\Maya2011\bin\python26.zip	hreading.py", line 525, in __bootstrap_inner
# self.run()
# File "Q:/someFolder\somePyFile.py", line 103, in run
# subprocess.call(self.cmd_args)
# File "C:\Program Files (x86)\Autodesk\Maya2011\bin\python26.zip\subprocess.py", line 499, in call
# return Popen(*popenargs, **kwargs).wait()
# File "C:\Program Files (x86)\Autodesk\Maya2011\bin\python26.zip\subprocess.py", line 650, in __init__
# errread, errwrite)
# File "C:\Program Files (x86)\Autodesk\Maya2011\bin\python26.zip\subprocess.py", line 855, in _execute_child
# startupinfo)
# WindowsError: [Error 2] The system cannot find the file specified

the tough part about debugging this is I only get the error on another individuals computer, mine is 64-bit win7 running maya 2011 which I would think makes no diff since the error in coming from inside maya’s version of subprocess. thought’s anyone?

the command being executed is :


bt = BatchThread(['C:/Program Files/Autodesk/Maya2011/bin/mayapy.exe',
                         '%s/fixItAgainTony.py'%self.tool_path,
                         self.root_path,
                         files,
                         cmd_file_name,
                         suffix])
bt.start()

batchThread starts a new thread that just takes that args list and puts it in subprocess.call

1- What happens if you don’t use another thread?
2- What happens if you use Popen directly?
3- Can you distill it down directly into a subprocess call and show us the failing code?

Maya (and some other GUI programs) on Windows has problems with subprocess and pipes.

1: I had it running without a thread before and had the same result
2: Funny thing actually, nothing happens, in fact, it’s really weird, it doesn’t error or run anything
3: Before I had the thread in there I had this call, it’s pretty much the same thing, I tried wrapping the path to mayapy in double qutoes as well but it didin’t make a difference.


subprocess.call(['C:/Program Files/Autodesk/Maya2011/bin/mayapy.exe',
                         '%s/fixItAgainTony.py'%self.tool_path,
                         self.root_path,
                         files,
                         cmd_file_name,
                         suffix])

Is there a “Tech-Art sanctioned” way to call system commands and/or how to use threading properly? I thought the interweb had provided enough examples, but I’ve had so many uncommon issues with this thing. I started out using os.system (quick and easy) and that would break since windows is dumb and puts a space in their folder names, which causes you to wrap the statements in double quotes to run in the command console and in python it still likes to error out saying "cannot file file or path c:/Program ". so although the command runs if I paste it into the command console, for whatever reason, wrapping in double quotes doesn’t seem to fix the space issue in the folder name. Some posts on stack overflow just said it’s just a bug so I switched to subprocess since most people recommend using that anyway, but using subprocess.Popen failed (like I said above, it just doesn’t seem to run), so then I used subprocess.call and although this works on my computer now I get this new error on this other computer.
The thing is I get this same error outside of maya when it comes to running subprocess with a standalone python application on the same computer having the issue, so I’m wondering if I should have them do a clean install of both python and maya? The thing that is most confusing is that it works for me and not for them.

Your problem is likely that Maya will likely only be installed under “C:/Program Files/Autodesk/Maya2011/” under certain circumstances. I bet his is installed elsewhere. For example C:/Program Files(x86)/Autodesk/Maya2011/bin/mayapy.exe

You should probably inspect the registry to see where it was installed rather than assuming…

ahhhhh, your argument is valid. I bet you are right, thanks! I will give it a shot.

I ran into a stack of issues with sub process on versions prior to 2012 now all of a sudden it seems to behave properly, I think I posted on here about one of them.