http://bugzilla.wpkg.org/show_bug.cgi?id=123
Rainer Meier <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |WONTFIX --- Comment #6 from Rainer Meier <[email protected]> --- Hi Peter, Unfortunately this is an issue which cannot be finally solved by WPKG as it is a bug in WSH scripting interpreter. There is a clear comment in WPKG source code for it: Unfortunately WSH is terribly broken when handling I/O streams from processes. AtEndOfStream blocks as well as ReadAll(), Read(x) and ReadLine(). So it's impossible to fetch STDOUT/ STDERR without blocking the main WPKG program. So either you can fetch the output or wait for the program to terminate, but not both. For WPKG it's more important to handle a timeout in order to handle programs which do not terminate properly or interactively ask for input. Unfortunately sub-processes seem to be blocked if they write more than 4k of data to STDOUT and/or STDERR buffer. So make sure your commands do not print too much on the console. If in doubt you might redirect STDOUT/STDERR to a file. For example by adding "> %TEMP%\myprog-out.txt 2>&1" to the command line. See <http://www.tech-archive.net/Archive/Scripting/microsoft.public.scripting.wsh/2004-10/0204.html> for a discussion on this topic. The code initially provided by Keith is still there too but it does not work. Instead it breaks the timeout feature as WSH is blocked in AtEndOfStream query or during flushing. So there is no way to do this with WSH it seems (let us know if you know a portable way of doing it supporting all our target platforms and not breaking any code). Until a solution is found (or provided by Microsoft) we have to live with the buffer limitation. In fact it's pretty easy to work-around. Just redirect your console output to NUL by appending ">NUL 2>&1" to your commands. This issue applies only to a very small amount of commands since most commands do not write anything to console. For those which do a very small amount hits the limit of 8k (Keith claims it's 8k while I had something like 4k in mind). The only work-around which could potentially be implemented by WPKG would be to append the NUL-redirect on each command executed. I've even tried that and it caused severe side-effects with more complex commands (some call %COMSPEC%, some call any other binary, some use pipes, some use redirects in complex command-lines) which is almost impossible to parse automatically assuring that no command is broken by messing around with the command line specified in the package. So I've decided to leave it as is and let the user handle the issue. The issue is well-known limitation of WSH and there is nothing we can do to fix it properly. In your case try the following: <install cmd='%COMSPEC% /C FOR /L %I IN (10,1,27) DO msiexec %MSI% /x {26A24AE4-039D-4CA4-87B4-2F832160%IFF} >NUL 2>&1'> <exit code='1605'/></install> -- Configure bugmail: http://bugzilla.wpkg.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug. ------------------------------------------------------------------------- wpkg-users mailing list archives >> http://lists.wpkg.org/pipermail/wpkg-users/ _______________________________________________ wpkg-users mailing list [email protected] http://lists.wpkg.org/mailman/listinfo/wpkg-users
