[wpkg-users] IO blocking packages, a solution for rarities...

[Keith Jones]

Hi,

 A long time ago, in a galaxy far, far away, I reported a bug and possible solution to Mangoo (http://bugzilla.wpkg.org/show_bug.cgi?id=123) to counter installers that generated huge amounts of output and caused WPKG.JS to block up because WScript had limited IO buffers. I've just encountered a similar issue, an installer that stopped working because it needed stdout, stdin and stderr to be open for it to write to and WScript.run doesn't create those streams.  It's one of those issues where there's no singular solution but I just found a neat and simple trick that might be useful and I thought I'd pass it on via the list for discussion prior to logging as an improvement. It was one of those lightbulb, gosh, I should have thought of this moments so it's bound to be wrong!

Anyway... If you find an installer grinds to a halt for no obvious reasons try the following;

1)      Create a folder (I called mine "tools" and put it directly under WPKG's folder)
2)      Add a variable in config.xml to point to it.
      e.g  <variables>
        <variable name='TOOLS' value='\\myserver \myshare\wpkg\tools'/>
        </variables>
3)      Create a .BAT file in that directory with a single line containing "@%*" (I called mine "launcher.bat")
      The @ prevents the line echoing to the screen
      The %* equates to the parameters sent to the bat file
      The single line effectively silently just runs the parameters you send to the batch file as a command
4)      When you encounter a problem command line replace it with a line that "launches" the command through that .bat file
e.g
      replace <install cmd='"\\myserver\myshare\mysoftware.exe" something' ><exit code='0' /><exit code='1605' /></install
      with  <install cmd='"%TOOLS%\launcher.bat" "\\myserver\myshare\mysoftware.exe" something' ><exit code='0' /><exit code='1605' /></install

 Hopefully, you'll then find that some of the awkward installers actually start working a bit more sensibly. It certainly seems to be a bit better to work with than adding "%comspec% /c <mycommandline>" , "start /wait <mycommandline>"" or tacking on "1>nul 2>nul" to the end of commands to avoid buffer overflow. It might actually be useful technique for WPKG to use internally.

Have fun folks,

 Keith

Keith Jones
Principal Technician
Brighton Business School

Support:                bbssupport (support.business at brighton.ac.uk<mailto:support.business at brighton.ac.uk>)
Photocopying:           bbsrepro (repro.business at brighton.ac.uk<mailto:repro.business at brighton.ac.uk>)
Support line:           x2182 (01273 642182<tel:01273642182>)
Direct line:            x2183 (01273 642183<tel:01273642183>)
Find us:                        Google Maps<http://maps.google.co.uk/maps/place?ftid=0x4875858bc60653f5:0x8af835530bc76baa&q=Mithras+House,+Lewes+Road,+Brighton&hl=en&ved=0CAwQ-gswAA&sa=X&ei=PZY6T_flCov14QSz9PlW>




___________________________________________________________
This email has been scanned by MessageLabs' Email Security
System on behalf of the University of Brighton.
For more information see http://www.brighton.ac.uk/is/spam/
___________________________________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.wpkg.org/pipermail/wpkg-users/attachments/20130528/b8a177f9/attachment-0002.html>