Execute VBS in a variable location?

[vyperhand]

I'm struggling to launch a VBS file via autoit using RunWait.  Due to the nature of the deployment tool I am using for said script, I only know that the .vbs files will be in the same directory as my AutoIt-generated .exe, but not what that path will be.  The path will look something like this:

c:\programdata\vendor\lots\of\folders\randomnumber

This is generated during deployment and I have no way of predicting the path - therefore, I am not sure how to call back to "same directory" in order to successfully launch the .vbs.

This line is as close as I have gotten - this fires off the cmd window, but it closes immediately with out information, and the .vbs is not launched.

RunWait (@ComSpec & " /c" & 'cscript.exe WORKPLEASE.vbs ALL /Q /NoCancel')

I thought /c might be the problem, but leaving out the /c element causes me not to even see the momentary CMD window flash by.  Any help will be greatly appreciated, and thanks in advance.

[water]

Add a space after " /c"

RunWait (@ComSpec & " /c " & 'cscript.exe WORKPLEASE.vbs ALL /Q /NoCancel')

 

[vyperhand]

Thanks Water.

Tried that, no change.  Still just a flash of a command window and the .vbs does not execute.

[water]

Then lets try to keep the window open:

RunWait (@ComSpec & " /k " & 'cscript.exe WORKPLEASE.vbs ALL /Q /NoCancel')

/c stands for "close the window", /k for "keep the window open".

[Subz]

You can just use @ScriptDir for example to point to the same folder as the script:

RunWait (@ComSpec & ' /c cscript.exe "' & @ScriptDir & '\&WORKPLEASE.vbs" ALL /Q /NoCancel')

 

[vyperhand]

Thanks Water and Subz.

Combining those two got the scripts to fire and leave the screen up for troubleshooting - but then for no explicable reason, the VBS gives a permissions error on trying to remove some registry keys.  This is extremely confusing, as the script works both when called manually from a command line or from a batch.  Just for grins, I even moved the batch into the auto-deployment folder where the .exe landed, and the batch works great... but calling it via the EXE I made with AutoIt doesn't.

I'll dig deeper into that, appreciate the help that at least got me this far.

[Subz]

Try and add #RequireAdmin at the top of your script, assuming the keys are HKLM keys or post your VB script and we can try and convert it to AutoIt

Edited February 19, 2018 by Subz

[vyperhand]

Let me try #RequireAdmin - the .vbs I'm trying to run isn't one I made myself, unfortunately.  It's one of MS's pre-published Office Removal .VBS monstrosities.  3926 lines, more than a minor effort to convert to AutoIt.  Happy to provide the file if you're feeling froggy, but it seems effort-prohibitive to me.

**Edit - # RequireAdmin didn't change the outcome.  Just for grins, used psexec to kick the .exe off under the system account, same issue.

Edited February 19, 2018 by vyperhand
Updated information.

[Subz]

Not sure if this would help, but here is what I used when upgrading our Office 2003/2007 clients to Office 2013

#RequireAdmin
Opt("ExpandVarStrings", 1)
;~ Uninstall Office 2003
If RegRead('HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{90110409-6000-11D3-8CFE-0150048383C9}', 'DisplayName') Then
    RunWait('@ComSpec@ /c cscript "@ScriptDir@\OffScrub03.vbs" PIA,PROPLUS /S /OSE /BYPASS 1 /NOCANCEL /Quiet', '', @SW_HIDE)
EndIf
;~ Uninstall Office 2007
If RegRead('HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{90120000-0011-0000-0000-0000000FF1CE}', 'DisplayName') Then
    RunWait('@ComSpec@ /c cscript "@ScriptDir@\OffScrub07.vbs" EXPDFXPS,PIA,PROPLUS /S /OSE /BYPASS 1 /NOCANCEL /Quiet', '', @SW_HIDE)
EndIf

 

[vyperhand]

Yep, that looks familiar all right.

 

#RequireAdmin
RunWait (@ComSpec & " /c " & 'cscript.exe offscrub07.vbs ALL /Q /NoCancel')
Run (@ComSpec & " /c " & "shutdown /r /t 30 /d P:4:1")

But for some reason, the first step of the VBS fails with a perms error regarding the registry when called from AutoIt.  Still digging into what might be causing that.  So the VBS fails, the sandbox system reboots, and I'm back to the drawing board.  I'll dig into this more tomorrow for sure.