[Python-bugs-list] [ python-Bugs-231273 ] [windows] os.popen doens't kill subprocess when interrupted
noreply@sourceforge.net
noreply@sourceforge.net
Sun, 14 Jul 2002 16:28:54 -0700
Bugs item #231273, was opened at 2001-02-07 03:43
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=231273&group_id=5470
Category: Windows
Group: Platform-specific
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Christophe Gouiran (cgouiran)
Assigned to: Mark Hammond (mhammond)
Summary: [windows] os.popen doens't kill subprocess when interrupted
Initial Comment:
Hi, in the following script I liked to make an interface to the contig program(http://www.sysinternals.com)
As the popen invocation can be a long time process (since it walks recursively trough directories) I press CTRL-C sometimes and the contig continues to run.
I use Python 2.0 (BeOpen version) under WinNT 4.0(SP 4)
Maybe I made a mistake in the following script ?
-------------------------------------------------
#! /usr/bin/env python
import sys;
import os;
import re;
content = ""
mm = re.compile("Processing (.+)?:\nFragments: (\d+)?");
output = os.popen("contig -a -s *.*");
while(1):
line = output.readline();
if line == '':
break
content += line;
status = output.close()
if status:
print("Error contig : "+`status`+"("+os.strerror(status)+")");
sys.exit(12);
print mm.findall(content)
----------------------------------------------------------------------
>Comment By: Mark Hammond (mhammond)
Date: 2002-07-15 09:28
Message:
Logged In: YES
user_id=14198
Checking in posixmodule.c;
/cvsroot/python/python/dist/src/Modules/posixmodule.c,v <--
posixmodule.c
new revision: 2.243; previous revision: 2.242
done
----------------------------------------------------------------------
Comment By: Tim Peters (tim_one)
Date: 2002-07-14 12:12
Message:
Logged In: YES
user_id=31435
Sure! Check it in. popen() isn't reliable under Win9x as-is
anyway -- it's not going to hurt anything to make it work
better <wink>.
----------------------------------------------------------------------
Comment By: Mark Hammond (mhammond)
Date: 2002-07-14 11:09
Message:
Logged In: YES
user_id=14198
*sigh* - I should have clicked re CREATE_NEW_CONSOLE.
I see no good reason for CREATE_NEW_CONSOLE. The popen code
was lifted from KB Q190351
(http://support.microsoft.com/default.aspx?scid=kb;EN-US;Q190351)
which uses this flag. In fact, almost all CreateProcess()
samples use this flag, however Q150956, which also deals
with redirection issues does not.
A search over MSDN reveals no reason we *must* use this
flag, and as we are redirecting all the standard handles I
can't think of any either <wink>. Indeed, removing this
flag appears to work fine, and does indeed fix this bug.
So shall I check it in and see what breaks <wink>?
----------------------------------------------------------------------
Comment By: Martin v. Löwis (loewis)
Date: 2002-07-12 20:51
Message:
Logged In: YES
user_id=21627
What is the rationale for using CREATE_NEW_CONSOLE? It seems
that it would be indeed more Unix-like if this wasn't used.
----------------------------------------------------------------------
Comment By: Tim Peters (tim_one)
Date: 2002-07-12 17:16
Message:
Logged In: YES
user_id=31435
It's hard to know what Windows intends. The docs say
"""
The ctrl+c and ctrl+break key combinations receive special
handling by console processes. By default, when a console
window has the keyboard focus, ctrl+c or ctrl+break is
treated as a signal (SIGINT or SIGBREAK) and not as
keyboard input. By default, these signals are passed to all
console processes that are attached to the console,
causing the system to call the control handler function or
functions associated with these processes. Detached
processes (GUI processes or console processes started
with the DETACHED_PROCESS or
CREATE_NEW_CONSOLE flag) are not affected.
"""
That seems clear enough at first glance; the problem is that
MS docs almost never say anything useful about how their
msvcrt functions map onto Win32 concepts. So, e.g., did
they intend that a process opened via popen() from a
console process share the console? Who knows?
Best guess is that they did, and at least on Win9x
Python's w9xpopen doesn't pass any special creation flags
to CreateProcess(). However,Python's
_PyPopenCreateProcess() *does* pass
CREATE_NEW_CONSOLE when it creates its child process,
so it seems no mystery (according to the docs) why Mark's
little progam doesn't kill off the child when the parent gets
Ctrl+C.
----------------------------------------------------------------------
Comment By: Martin v. Löwis (loewis)
Date: 2002-07-11 18:22
Message:
Logged In: YES
user_id=21627
Delivery of Ctrl-C (SIGINT) is platform-specific; I see no
need to provide a uniform behaviour across systems.
On Unix, the terminal device sends SIGINT to all processes
that have this terminal as their controlling terminal; the
idea is that logging off that terminal will also terminate
all incomplete processes (unless they have been detached
from the terminal). If Windows treats Ctrl-C in a different
way, traditionally, I think platform conventions should
overrule Python-uniformness.
----------------------------------------------------------------------
Comment By: Mark Hammond (mhammond)
Date: 2002-07-11 16:57
Message:
Logged In: YES
user_id=14198
Martin: you wrote:
> I can't see the bug here, though - why *should*
> terminating the parent process terminate the child
> processes also?
I think there is a bug here - certainly a difference
compared to Linux. Consider a script popen_child.py:
import time
for i in range(20):
print i
time.sleep(1)
and consider popen_parent.py
import os
f=os.popen("python popen_child.py")
print f.read()
f.close()
When popen_parent.py is executed on Linux and I press
Ctrl+C, I see *both* processes terminate with
KeyboardInterrupt. On Windows, the parent process is killed
but the child continues until it dies of other causes.
I may be able to fix it but now I am not even sure it is a
bug :)
----------------------------------------------------------------------
Comment By: Martin v. Löwis (loewis)
Date: 2001-06-05 06:46
Message:
Logged In: YES
user_id=21627
A patch for this problem is in progress at
https://sourceforge.net/tracker/index.php?func=detail&aid=403743&group_id=5470&atid=305470
I can't see the bug here, though - why *should*
terminating the parent process terminate the child
processes also?
----------------------------------------------------------------------
Comment By: Tim Peters (tim_one)
Date: 2001-02-10 10:50
Message:
Poor Mark. I assign anything with "popen + Windows" to you, because you're the only one who ever makes progress on them <wink>. Offhand, I can't see how Ctrl+C directed at Python *could* interrupt a spawned process.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=231273&group_id=5470