subprocess.Popen not replacing current process?

[goodman]

Note: Our server is a Linux machine, but we're restricted to Python
2.4.

Hi, I'm wondering why subprocess.Popen does not seem to replace the
current process, even when it uses os.execvp (according to the
documentation: http://docs.python.org/library/subprocess.html#subprocess.Popen).
Specifically, when I try to kill a spawned process with Ctrl-C, the
SIGINT does not seem to be sent to the spawned process.

Some background: I have a Python script that calls shell scripts or
commands. It does not need to regain control after calling these
scripts or commands, so up to now I've been using an os.exec* command.
It seems the subprocess module is the recommended way for spawning
processes, but in this case perhaps it's better I stick with os.exec*?
I've seen plenty of discussion about catching KeyboardInterrupt in the
parent process and then manually killing the child, but (1) I can't
use Popen.kill() on Python 2.4, and (2) this level of process
management seems like overkill (pardon the potential for puns) in my
case.

Thanks for any help.

 

[Lawrence D'Oliveiro]

In message

Hi, I'm wondering why subprocess.Popen does not seem to replace the
current process, even when it uses os.execvp (according to the
documentation:
http://docs.python.org/library/subprocess.html#subprocess.Popen).

You’ll notice that in the list at the top of the functions that subprocess
replaces, there are no os.exec* entries. subprocess is only for spawning new
processes; if all you need to do is an exec, do an exec
<http://docs.python.org/library/os.html#process-management>; subprocess
can’t offer anything to make that any simpler.

 

[goodman]

Note: Our server is a Linux machine, but we're restricted to Python
2.4.

Hi, I'm wondering why subprocess.Popen does not seem to replace the
current process, even when it uses os.execvp (according to the
documentation:http://docs.python.org/library/subprocess.html#subprocess.Popen).
Specifically, when I try to kill a spawned process with Ctrl-C, the
SIGINT does not seem to be sent to the spawned process.

Some background: I have a Python script that calls shell scripts or
commands. It does not need to regain control after calling these
scripts or commands, so up to now I've been using an os.exec* command.
It seems the subprocess module is the recommended way for spawning
processes, but in this case perhaps it's better I stick with os.exec*?
I've seen plenty of discussion about catching KeyboardInterrupt in the
parent process and then manually killing the child, but (1) I can't
use Popen.kill() on Python 2.4, and (2) this level of process
management seems like overkill (pardon the potential for puns) in my
case.

Thanks for any help.

Following up, I can get the effect I want with the following:

try:
p = subprocess.Popen([cmd, arg1, arg2])
p.wait()
except KeyboardInterrupt:
import signal
os.kill(p.pid, signal.SIGKILL)

....but like I said, I don't think I should be managing this myself,
since I don't need to return from the new process. How can I make the
new process handle its own signals?

 

[goodman]

In message


You’ll notice that in the list at the top of the functions that subprocess
replaces, there are no os.exec* entries. subprocess is only for spawning new
processes; if all you need to do is an exec, do an exec
<http://docs.python.org/library/os.html#process-management>; subprocess
can’t offer anything to make that any simpler.

Thanks Lawrence. Forgive my recent followup, as I posted it before I
saw your message. I noticed that the exec*s were not replaced by
subprocess, so that makes sense to just use exec. Though I'm still a
little confused how, if subprocess.Popen is using os.execvp, it still
maintains control of things like interrupts.

Anyway, my problem is solved. Thanks!

 

[Lawrence D'Oliveiro]

In message

Though I'm still a little confused how, if subprocess.Popen is using
os.execvp, it still maintains control of things like interrupts.

The implied point, being that we are spawning subprocesses, is that there is
a fork call before the exec.

Anyway, my problem is solved. Thanks!

Glad to hear it.