http://bugzilla.wpkg.org/show_bug.cgi?id=155 Rainer Meier <r.meier at wpkg.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |r.meier at wpkg.org Status|NEW |ASSIGNED --- Comment #1 from Rainer Meier <r.meier at wpkg.org> 2009-04-19 11:06:47 --- Hi Jason, I can confirm that you're right. As soon as the AtEndOfStream property (it's not a function/method). It seems to cause the forked CMD not to exit and keeps waiting for it to be closed. When it exits (manually or by implicit exit) then the parent process continues too. Yesterday I spent half a day to find a way to flush the output AND allow forking processes. However I did not yet succeed. Personally from my (mainly Unix) experience I would call it a bug but probably it's a "design feature" of Windows. Currently I am thinking about removing the flush code again since this behavior is really unexpected. If I want to run a sub-command using "start" (without /wait parameter) then I would expect that my parent script (the one calling "start") exits immediately. So let me investigage a bit further and then I will either revert the changes to flush the output (which instead would make commands with huge output of several kB to "hang") or to implement a working fix. As this exec() method is quite a crucial part of WPKG it's really important for a fix to work properly and in all environments. So I don't want to include any dirty workarounds and tricks which might fail in some environments. Then I would prefer not to flush the output and just document that the command run should not print more than xy kB on the console. I think usually no installer is doing this anyway and if it does it might be wrapped with a CMD script or its output being redirected to NUL. -- Configure bugmail: http://bugzilla.wpkg.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug. |