I'm not sure... but if it works without we can cut it huh? I was under
the impression that unless you ran a shell as intermediary you had to
use absolute paths for everything....(I thought that using shell would
provide the env) but it seems I was on crack.
>> And if anything hangs it can still be killed by Process Viewer.
I was more thinking more for the automated build page, where a
"client" could be left for days without supervision.
A single process os.kill using TerminateProcess would then work if
there was no intermediary shell huh? If shell = 0 it won't start the
(shell) cmd.exe or command.com etc first?
......
OK, I just tried and indeed it thats what happens using shell=0. I
used process explorer and run_tests.py only creates python.exe
children. No process tree == win98 happiness.
.....
I removed the taskkill, pskill os.kill() hack and replaced it with a
method on the async Popen object. If not windows, it uses os.kill()
if subprocess.mswindows:
def kill(self):
"""kill function for Win32"""
handle = win32api.OpenProcess(1, 0, self.pid)
return (0 != win32api.TerminateProcess(handle, 0))
So, we should now be good for win98+ and *nix ?
Thanks for your help Lenard.
Lenard Lindstrom wrote:
This is not a big issue. I don't think there is anything like a
process tree in Windows 98. And if anything hangs it can still be
killed by Process Viewer. The timeout works, so that is all that
really matters. Just out of curiosity though, why use a shell as an
intermediary. Why isn't the Python interpreter executed directly in
the subprocess?
>>> cmd = 'python -c "print \\"Hello.\\""'
>>> print cmd
python -c "print \"Hello.\""
>>> import subprocess
>>> out = open('C:/windows/desktop/stdout.txt', 'w')
>>> s = subprocess.Popen(cmd, stdout=out)
>>> s.wait()
0
>>> out.close()
>>> print open('C:/windows/desktop/stdout.txt').read()
Hello.
Lenard
Nicholas Dudfield wrote:
Lenard,
Weird, XP? Vista? I'm on XP SP3
By passing an env = {} to the Popen constructor temporarily to
remove PATH from the environment it fails my end.
D:\Nick\PyGame\trunk>run_tests.py -s
No way of killing unruly processes. Try installing sysinternals
pskill and placi
ng on %PATH%.
I found a recipe for TerminateProcess, but it didn't kill child
processes so it would stop the run_tests from hanging but on mine at
least, python would call cmd which would in turn call python. It
would only kill cmd.exe, leaving python to run rampant.
cmd
python run_tests.py
cmd python
xxxx_test.py
But yeah, we really need it to be consistent however it works. It
would be nice if it would kill process trees also.
You are more than welcome to make any changes.
To run a test_suite with a test that "while True: pass"
$ run_tests.py -s -f infinite_loop
I have been meaning to add that to the run_tests test.
Cheers
Lenard Lindstrom wrote:
Hi,
I tried running the tests in subprocess mode an everything passed.
Great, except I didn't have either pskill or taskkill installed.
When checking for the programs Popen.wait() always returned 0, even
when the program was not found. So it incorrectly assumed I had
pskill installed (first in the list). Anyway, since pywin32 is
already required, why not do the TerminateProcess system call
directly, making pskill or taskkill unnecessary. If interested I
can making the necessary changes to async_sub.py.