How do subprocess.Popen("ls | grep foo", shell=True) with shell=False?

[Nobody]

On Thu, 10 Jun 2010 08:40:03 -0700, Chris Seberino wrote:

> On Jun 10, 6:52 am, Nobody <nob... at nowhere.com> wrote:
>> Without the p1.stdout.close(), if the reader (grep) terminates before
>> consuming all of its input, the writer (ls) won't terminate so long as
>> Python retains the descriptor corresponding to p1.stdout. In this
>> situation, the p1.wait() will deadlock.
>>
>> The communicate() method wait()s for the process to terminate. Other
>> processes need to be wait()ed on explicitly, otherwise you end up with
>> "zombies" (labelled "<defunct>" in the output from "ps").
> 
> You are obviously very wise on such things.  I'm curious if this
> deadlock issue is a rare event since I'm grep (hopefully) would rarely
> terminate before consuming all its input.

That depends; it might never start (missing grep, missing shared
library), segfault, terminate due to a signal, etc. Also, the program
might later be modified to use "grep -m <count> ..." which will terminate
after finding <count> matches.

> Even if zombies are created, they will eventually get dealt with my OS
> w/o any user intervention needed right?

They will persist until the parent either wait()s for them (I think that
this will happen if the process gets garbage-collected) or terminates. For
short-lived processes, you can forget about them; for long-lived
processes, they need to be dealt with.

> I'm just trying to verify the naive solution of not worrying about
> these deadlock will still be ok and handled adequately by os. :)

Deadlock is deadlock. If you wait() on the child while it's blocked
waiting for your Python program to consume its output, the wait() will
block forever.