Python to execute within parent process

Coding
1

Hey there,
So this is a bit of a weird question and I might fail to explain it properly.

Our studio app has no python at the moment, but I can get it to run any shell command from within the app.
So I can do

run python script.py

Any output from the python prints out here, just like it would if I ran it in the shell.
(ie if I do a print “myName”, I see myName in the apps output window)

But if I do a:

subprocess.popen(['echo','myName'])

It runs the echo command in the shell.

Python is obviously aware of it’s parent process and hence knows where to print things.
Is there a way to find out what it is so I can pass commands to it?

Obviously, I can’t mention too much about the program since it’s all NDA proprietary…and having no luck finding an answer at work.

Thanks. Even if the answer is ‘its not possible’, it puts me out of my misery.

Cheers
Dhruv

2

Not sure if I understand correctly, but it should be possible to run python.exe as subprocess and capture stdout and stderr and also feed it commands via stdin. I don’t think python.exe is aware that it is a subprocess though - I think it behaves just as it always does, using standard IO channels.

3

Mayhaps this might clear it up a bit. Sorry, its just an odd requirement.

essentially:
1)The scriptEditor of the app is like a shell itself. Kind of like a dumber version of Maya’s script editor.
2)Running python from it via (run python pyscript.py) opens up the systems python interpreter as a subprocess.
3)Printing from python prints to the apps shell.
4)Running a subprocess.popen from python sends it to the systems shell. << I would like to send it to the apps shell instead.

Unfortunately the main app has no direct support for python. It just opens up the systems interpreter and waits for it to relinquish control. Just as if you enter the interpreter in the shell.

Just more info: its on Linux with a tcsh shell.

4

Just wondering if anyone had any ideas on this one? Sorry for the bump

5

If all you want is read-only view of python output, it sounds like you could get the output by catching it in your subprocess and printing it again from the root pyscript.py – though it’s hard to tell without seeing anything.

However this is going to be read-only unless the program has some explicit ability to read from stdin instead of just displaying what comes back. What happens if pyscript.py looks like this:

import sys
stdout.write(" > ")
input = sys.stdin.readline()
sys.stdout.write("got " + input)

6

Hey Theodox, man the stdout actually works great.
The stdin part hangs, because I assume it’s waiting for the python process to finish before it will give user back control.

(also sorry for the delayed response…got caught up in a lot of other things :’( )

Cheers. I’m going to keep trying for better integration. Thank you.

7

[QUOTE=dgovil;17289]Hey Theodox, man the stdout actually works great.
The stdin part hangs, because I assume it’s waiting for the python process to finish before it will give user back control.

(also sorry for the delayed response…got caught up in a lot of other things :cry: )

Cheers. I’m going to keep trying for better integration. Thank you.[/QUOTE]

Hanging is what I’d expect – python is waiting for some kind of input from the program that fired the python off in the first place. Unless the hosting program has something like a named pipe connection to your python, nothing will ever be input.

Since you have the ability to start a new python, you can pass it arguments and get at those with sys.argv – that would let you fire the python instance from the main app, process the arguments, and print out the results or do something based on the args before returning control to the main app. You won’t be able to ‘interactively’ control python, though, unless the main app can write to what python thinks of as stdin – which is unlikely to be a ‘free’ feature in your main app.

If your python looks like this:


import sys

if __name__ == '__main__':
    args = sys.argv
    for item in args:
        print 'got', item  # I'm guessing that in your context this and sys.stdout.write are interchangeable.....

and your app calls:


run python "myscript.py" "string" "number"

you should get back


got myscript.py
got string
got number

(argv[0] is the script passed in)

Presumably you could get some functionality out of it this way – but you’ll have significant startup costs, since each exchange between the main app and python will start a new python instance – you won’t be able to persist it between invocations, since it won’t return data to the main app until it exits. However the python instance can talk to outside stuff and summarize results for the main app – for example, you could talk to an always-on server (maybe another python app running RPyC or a web service running on your machine) via http and return the results to your app that way:

(App) >>> (run myscript.py arg arg arg) >> RPC call >> (server “<dosomething><arg><arg><arg><dosomething>”) >> back to myscript as XML >> back to App as text

8

Thank’s Theodox. Actually I just had a similar pass through idea like yours today…but looking at how to implement it was giving me a headache :’(
Thankfully, after much digging around company resources, looks like there is a really solid python communication script (still have to write wrappers for the commands).
People just have a weird habit of telling me stuff’s not possible here :stuck_out_tongue: Till you find the one guy who’se like “Oh yeah, here, dead simple”