Issue231273
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.
Created on 2001-02-06 16:43 by cgouiran, last changed 2022-04-10 16:03 by admin. This issue is now closed.
Messages (10) | |||
---|---|---|---|
msg3232 - (view) | Author: Christophe Gouiran (cgouiran) | Date: 2001-02-06 16:43 | |
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) |
|||
msg3233 - (view) | Author: Tim Peters (tim.peters) * ![]() |
Date: 2001-02-09 23:50 | |
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. |
|||
msg3234 - (view) | Author: Martin v. Löwis (loewis) * ![]() |
Date: 2001-06-04 20:46 | |
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? |
|||
msg3235 - (view) | Author: Mark Hammond (mhammond) * ![]() |
Date: 2002-07-11 06:57 | |
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 :) |
|||
msg3236 - (view) | Author: Martin v. Löwis (loewis) * ![]() |
Date: 2002-07-11 08:22 | |
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. |
|||
msg3237 - (view) | Author: Tim Peters (tim.peters) * ![]() |
Date: 2002-07-12 07:16 | |
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. |
|||
msg3238 - (view) | Author: Martin v. Löwis (loewis) * ![]() |
Date: 2002-07-12 10:51 | |
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. |
|||
msg3239 - (view) | Author: Mark Hammond (mhammond) * ![]() |
Date: 2002-07-14 01:09 | |
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>? |
|||
msg3240 - (view) | Author: Tim Peters (tim.peters) * ![]() |
Date: 2002-07-14 02:12 | |
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>. |
|||
msg3241 - (view) | Author: Mark Hammond (mhammond) * ![]() |
Date: 2002-07-14 23:28 | |
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 |
History | |||
---|---|---|---|
Date | User | Action | Args |
2022-04-10 16:03:42 | admin | set | github: 33860 |
2001-02-06 16:43:12 | cgouiran | create |