http://bugzilla.wpkg.org/show_bug.cgi?id=155 --- Comment #3 from Rainer Meier <r.meier at wpkg.org> 2009-04-20 18:37:58 --- My personal opinion here is that such a "flush" attribute on command level would be too complicated and its functionality would (even assuming the best available documentation) confuse lots of users. We would have lots of requests on the mailing list asking what it is and finally we would get even more requests of people using flush=true with forked sub-shells (which could create a "hang" then) or using flush=false with commands printing lots of information. Debugging it is difficult and for the WPKG team it's even almost impossible to do so because we don't know how the commands executed are behaving and as a result we cannot say if it should be set to true or false because it depends on the application run. I would really prefer here not to flush at all because a "hanging" command for 1 hour can be detected by users and the fix for it is simple: Just execute the command and wrap it into a "%COMSPEC% /c <command> > %TEMP%\install.log" so write the output to some text file instead. Moreover it's not clear yet how much an application can really print to the buffer until it blocks - and even worse this buffer size might be different for different OS or WSH versions. So for the moment I really prefer not to let this flush/noflush decision up to the user. Either it needs to be handled completely transparently and configuration-less or we have to keep possible problems in mind while debugging. -- Configure bugmail: http://bugzilla.wpkg.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug. |