Smart questions
Smart answers
Smart people
Join Tek-Tips Forums

Member Login

Remember Me
Forgot Password?
Join Us!

Come Join Us!

Are you a
Computer / IT professional?
Join Tek-Tips now!
  • Talk With Other Members
  • Be Notified Of Responses
    To Your Posts
  • Keyword Search
  • One-Click Access To Your
    Favorite Forums
  • Automated Signatures
    On Your Posts
  • Best Of All, It's Free!

Join Tek-Tips
*Tek-Tips's functionality depends on members receiving e-mail. By joining you are opting in to receive e-mail.

Posting Guidelines

Promoting, selling, recruiting, coursework and thesis posting is forbidden.
Jobs from Indeed

Link To This Forum!

Partner Button
Add Stickiness To Your Site By Linking To This Professionally Managed Technical Forum.
Just copy and paste the
code below into your site.

Problem with not waiting for command to finish executingHelpful Member!(3) 

billieT (MIS) (OP)
17 Apr 05 22:00
I'm trying to write a wee script to install Exchange + patches all at once. This is what I have so far:


Option Explicit
Dim FSO, WshShell, result
Set FSO = CreateObject("Scripting.FileSystemObject")
Set WshShell = WScript.CreateObject("WScript.Shell")
result = WshShell.Run("Exchange2003\SETUP\I386\SETUP.EXE /unattendfile unattend.ini", 1, TRUE)
if result=0 then result = WshShell.Run("WindowsServer2003-KB831464-x86-ENU.exe /quiet /norestart", 1, TRUE)
...[serveral more patches]
if result=0 then wscript.echo ("Done!" & vbcrlf & vbcrlf & "Please REBOOT now.")

For some reason, instead of waiting for each line to finish executing, the script immediately starts processing the next line. The reason I chose vb was to avoid having to do the whole "command /c start /w" routine in DOS. If I have to do that here as well, I might as well do it in DOS.

If I'm doing something obviously stupid, please let me know.
markdmac (MIS)
18 Apr 05 0:33
Take a look at Woolsdog's post in this thread:


I hope you find this post helpful.  



billieT (MIS) (OP)
18 Apr 05 1:18
All that Woolsdog suggests is using a variable instead of the TRUE value for bWaitOnReturn.

Since I'm explicitly setting it as TRUE, I don't see how using a variable is going to be any help whatsoever. Maybe I'll try removing the spaces.
Helpful Member!  tsuji (TechnicalUser)
18 Apr 05 2:30

It depends very much on the implementation of setup.exe or any other application at that position.

Let's say setup.exe itself run as process A. Process A does some nominal verification then spawns a process B, the real installation engine, then close itself out. In this case, the bWaitOnReturn has done its work and the control will hand to the next statement. However, the process B is still running. That is out of the control of the bWaitOnReturn.

regards - tsuji
billieT (MIS) (OP)
18 Apr 05 4:16
Bummer, that would most certainly be the case with the Exchange setup. And it also explains why the parts where I'm actually doing FSO stuff or running an commmand-line exe (which is echoing back to screen) are working as expected.

Thanks very much for the pointer, tsuji.
Helpful Member!(2)  fstrahberger (Programmer)
18 Apr 05 11:18

use WshShell.Exec instead of WshShell.Run and wait until the process has finished.


' execute commandline and get result into strResult
Set oWsc = CreateObject("WScript.Shell")
Set oExec = oWsc.Exec(("Exchange2003\SETUP\I386\SETUP.EXE /unattendfile unattend.ini")
' wait until finished
Do While oExec.Status <> 1
    WScript.Sleep 100
' get output from StdOut and StdErr
strResult = oExec.StdOut.ReadAll() & oExec.StdErr.ReadAll()
Set oExec = Nothing

billieT (MIS) (OP)
18 Apr 05 19:52
Thanks, fstrahberger, I did consider throwing a "sleep" command in there as well, but I didn't think of doing a loop to keep checking. I'm not that familiar with wscript.exec either.

Thanks again for the pointer!
tsuji (TechnicalUser)
19 Apr 05 5:05
I do _not_ think that .exec improves as such the situation as observed using .run in this particular application and in the general aspect. Just to clarify for other readers.
- tsuji

Reply To This Thread

Posting in the Tek-Tips forums is a member-only feature.

Click Here to join Tek-Tips and talk with other members!

Back To Forum

Close Box

Join Tek-Tips® Today!

Join your peers on the Internet's largest technical computer professional community.
It's easy to join and it's free.

Here's Why Members Love Tek-Tips Forums:

Register now while it's still free!

Already a member? Close this window and log in.

Join Us             Close