This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author belopolsky
Recipients belopolsky, wolfy
Date 2009-01-06.08:28:31
SpamBayes Score 0.013760434
Marked as misclassified No
Message-id <1231230515.34.0.440652674959.issue4855@psf.upfronthosting.co.za>
In-reply-to
Content
This really belongs to python-list rather than the tracker.  It is not 
correct that with shell=False Popen reuses the thread of control of the 
calling process.  You seem to be confusing blocking and reusing the 
thread of control.  Popen always creates a new thread of control using a 
fork() call.  The  proc.stdout.readline() will block until the process 
produces a full line of output, which is what anyone would expect.

It is not clear what you are trying to achieve.  Here is an example 
session:

>>> from subprocess import *
>>> p = Popen(['sleep', '10000'])
>>> p.kill()
>>> p.wait()
-9

or using a different signal (SIGINT = 2):

>>> p = Popen(['sleep', '10000'])
>>> p.send_signal(2)
>>> p.wait()
-2

The wait function blocks until the process terminates and returns the 
status (negative of the signal number in case of exit on signal).  What 
else are you trying to achieve?

Your proposals don't make much sense:

1) "child_pid()"  - what should it return if the shell command spawns 
more than one process? For example if the command contains |'s or 
multiple &'s?

2) "Signalling the children of the shell" - read the manual page for 
your shell.  Foreground processes receive most of the signals that way.  
Background processes only get a SIGHUP.

3) "proc.pid returns the command's PID" - there is no such thing: a 
command can create any number of processes.

4) "simple command to query all the childs PIDs" - without 
reimplementing shell in python to parse the command string, it is 
impossible to tell which subprocesses are spawned by a given Popen call.  
A function that returns all children of the given process can be 
written, but will be expensive on most systems because it will require a  
search over the entire process table.

In short, this report is invalid.
History
Date User Action Args
2009-01-06 08:28:35belopolskysetrecipients: + belopolsky, wolfy
2009-01-06 08:28:35belopolskysetmessageid: <1231230515.34.0.440652674959.issue4855@psf.upfronthosting.co.za>
2009-01-06 08:28:34belopolskylinkissue4855 messages
2009-01-06 08:28:32belopolskycreate