[wpkg-users] [Bug 123] Executed commands that lock installation process. - Tentative Solution(s) attached :-)

[bugzilla-daemon at bugzilla.wpkg.org]

http://bugzilla.wpkg.org/show_bug.cgi?id=123

Rainer Meier <r.meier at wpkg.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|                            |WONTFIX

--- Comment #6 from Rainer Meier <r.meier at wpkg.org>  ---
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.