[issue1220212] os.kill on windows
Brian Curtin cur...@acm.org added the comment: Ported to py3k in r80008. FAQ text updated in r80009 and r80010. -- resolution: - fixed status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1220212 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1220212] os.kill on windows
anatoly techtonik techto...@gmail.com added the comment: FAQ should be updated http://www.python.org/doc/faq/windows/#how-do-i-emulate-os-kill-in-windows -- nosy: +techtonik ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1220212 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1220212] os.kill on windows
Brian Curtin cur...@acm.org added the comment: How about something like this patch? -- Added file: http://bugs.python.org/file16765/faq_update.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1220212 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1220212] os.kill on windows
anatoly techtonik techto...@gmail.com added the comment: Seems good to me, even though I'd rewrite some parts like this: - Prior to Python 2.7 and 3.2, to terminate a process, you can use ctypes:: + Prior to Python 2.7 and 3.2, you can use linksomehow:`ctypes` to terminate a process:: ... In newer Python versions :func:`os.kill` works on Windows with the additional feature of being able to send CTRL+C and CTRL+BREAK to console subprocesses that understand these signals. ... -- anatoly t. On Mon, Apr 5, 2010 at 6:38 PM, Brian Curtin rep...@bugs.python.org wrote: Brian Curtin cur...@acm.org added the comment: How about something like this patch? -- Added file: http://bugs.python.org/file16765/faq_update.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1220212 ___ -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1220212 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1220212] os.kill on windows
Michael Foord mich...@voidspace.org.uk added the comment: After discussion with Brian it seems like it should be possible for os.kill(...) on Windows to support both pids *and* process handles. This seems ideal. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1220212 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1220212] os.kill on windows
Changes by Brian Curtin cur...@acm.org: Removed file: http://bugs.python.org/file16704/issue1220212.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1220212 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1220212] os.kill on windows
Brian Curtin cur...@acm.org added the comment: Michael, do you have an example of something which returns a handle? This current patch doesn't work with handles, but it wouldn't be hard to add it. I could make it work with the _handle object of a Popen object, but you could just as easily call os.kill on the pid of the Popen object. I don't know of any Python-wide handle object...I know subprocess has it's own, and don't really know what other functions are returning handles. Anyways, this patch includes an additional test script which uses ctypes to setup a console control handler, and CTRL_BREAK_EVENT is tested successfully. However, CTRL_C_EVENT is not. See http://msdn.microsoft.com/en-us/library/ms686016%28v=VS.85%29.aspx for details, but I'm not able to get the subprocess to work with CTRL+C. Calling SetConsoleCtrlHandler(NULL, FALSE) either in the script, test_os, or in _subprocess.c does not change anything, although it seems that it should. The CTRL_C_EVENT test is currently skipped in the patch until I can figure that out. -- nosy: +dino.viehland Added file: http://bugs.python.org/file16739/issue1220212.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1220212 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1220212] os.kill on windows
Michael Foord mich...@voidspace.org.uk added the comment: According to earlier discussion in this issue os.spawn() return process handles on Windows. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1220212 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1220212] os.kill on windows
Brian Curtin cur...@acm.org added the comment: Committed to trunk in r79633 after talking with Michael about it. I'll forward port it after the 2.7 beta goes out. -- assignee: - brian.curtin stage: - committed/rejected type: - feature request ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1220212 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1220212] os.kill on windows
Brian Curtin cur...@acm.org added the comment: Here is a patch with some tests and doc changes. I'm having trouble coming up with tests which will work with CTRL_C_EVENT and CTRL_BREAK_EVENT. Based on my understanding of GenerateConsoleCtrlEvent, I figured this example (http://msdn.microsoft.com/en-us/library/ms685049%28v=VS.85%29.aspx) would be receptive to CTRL+C when started as a subprocess, but it doesn't work. I also figured python -c input() started as a subprocess could be killed with CTRL_C_EVENT, but it doesn't work either. -- Added file: http://bugs.python.org/file16703/issue1220212.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1220212 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1220212] os.kill on windows
Changes by Brian Curtin cur...@acm.org: Removed file: http://bugs.python.org/file16703/issue1220212.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1220212 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1220212] os.kill on windows
Brian Curtin cur...@acm.org added the comment: Removed an unnecessary goto and fixed a few tab/space inconsistencies (ugh). -- Added file: http://bugs.python.org/file16704/issue1220212.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1220212 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1220212] os.kill on windows
Michael Foord mich...@voidspace.org.uk added the comment: To make it clear, even though it would be incomplete, a partial implementation of os.kill(...) for Windows would be very useful and provide some level of compatibility with applications that use os.kill (so even if os.kill(...) duplicates functionality in other modules - although that was disputed - it should be provided for compatibility reasons). An implementation similar to the IronPython one is probably the best that can be managed and would still be useful: accepting only signal.SIGINT and signal.SIGBREAK and first trying Kernel32.GenerateConsoleCtrlEvent, falling back to killing the process. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1220212 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1220212] os.kill on windows
Michael Foord mich...@voidspace.org.uk added the comment: To make it clear, even though it would be incomplete, a partial implementation of os.kill(...) for Windows would be very useful and provide some level of compatibility with applications that use os.kill (so even if os.kill(...) duplicates functionality in other modules - although that was disputed - it should be provided for compatibility reasons). An implementation similar to the IronPython one is probably the best that can be managed and would still be useful: accepting only signal.SIGINT and signal.SIGBREAK and first trying Kernel32.GenerateConsoleCtrlEvent, falling back to killing the process. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1220212 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1220212] os.kill on windows
Changes by Michael Foord mich...@voidspace.org.uk: -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1220212 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1220212] os.kill on windows
Changes by Michael Foord mich...@voidspace.org.uk: -- nosy: +brian.curtin ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1220212 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1220212] os.kill on windows
Martin v. Löwis mar...@v.loewis.de added the comment: So, Michael, what do you think: should os.kill expect a process handle, or a process ID? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1220212 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1220212] os.kill on windows
Michael Foord mich...@voidspace.org.uk added the comment: Hmm... well my particular use case is that it should work with the value returned by os.getpid(). If that is a process handle then it is nice and convenient to just use process handles. The docs don't specify so I bet it returns a pid. :-( However Brian Curtin might want to weigh in on this as he has been looking at implementing this and there might be constraints. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1220212 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1220212] os.kill on windows
Brian Curtin cur...@acm.org added the comment: I have this working with process IDs and my vote would be to keep it that way, as it would stay in-line with the other platforms, and it seems to work so far. I would imagine that was also IronPython's goal. I'm still working on the test portion of the patch. It should be ready shortly. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1220212 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1220212] os.kill on windows
Michael Foord mich...@voidspace.org.uk added the comment: It would be really useful to be able to send signal.SIGINT to processes on Windows using os.kill(...). The patch as described sounds like it would have a different signature to the standard implementation of os.kill(...) which takes a pid and a signal type. IronPython 2.7 will have an os.kill implementation. Looks like it only supports signal.SIGINT and signal.SIGBREAK and just calls: Process toKill = Process.GetProcessById(pid); toKill.Kill() -- nosy: +michael.foord ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1220212 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1220212] os.kill on windows
Changes by Michael Foord mich...@voidspace.org.uk: -- versions: +Python 2.7, Python 3.2 -Python 2.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1220212 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1220212] os.kill on windows
Michael Foord mich...@voidspace.org.uk added the comment: I'm wrong. First IronPython tries: NativeSignal.GenerateConsoleCtrlEvent(PythonSignal.CTRL_C_EVENT, ...) But with the comment: //The following calls to GenerateConsoleCtrlEvent will fail under //most circumstances. We'll try them any ways though as this seems //to be the only mechanism in Windows to send signals to processes It falls back to just killing the process. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1220212 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1220212] os.kill on windows
Michael Foord mich...@voidspace.org.uk added the comment: Aaaand the IronPython implementation of NativeSignal.GenerateConsoleCtrlEvent(PythonSignal.CTRL_C_EVENT, ...) delegates to Kernel32.GenerateConsoleCtrlEvent. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1220212 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1220212] os.kill on windows
Changes by Anders J. Munch [EMAIL PROTECTED]: -- nosy: +andersjm ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1220212 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1220212] os.kill on windows
Changes by Trent Nelson [EMAIL PROTECTED]: -- nosy: +Trent.Nelson _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1220212 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1220212] os.kill on windows
Technologov added the comment: Yes, this feature would be very important for me too... Anybody knows, _when_ it will be integrated into Python ? If this bugzilla supports email notifications, Please add me as CC for this bug. -Technologov -- nosy: +Technologov _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1220212 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1220212] os.kill on windows
Christian Heimes added the comment: This should be implemented differently. Users should substitute their popen and exec calls with subprocess. The subprocess.Popen class should gain two new methods terminate() and send_signal(int) where send_signal is restricted to SIGKILL (+SIGTERM ?) on Windows. The idea was discussed on the Python dev list early last year. -- nosy: +tiran versions: +Python 2.6 -Python 2.5 _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1220212 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1220212] os.kill on windows
Miki Tebeka added the comment: Users should substitute their popen and exec calls with subprocess As long as popen and exec are available, users are free to use them (and probably will :) The Popen(...).terminate() works only if I'm the one who started the process. However there are cases where I want to kill all running python processes. The pids to be killed will come from somewhere else (ps, plist, ...). _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1220212 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
