I have the maintenance of an old software written in VB6 that I have had to change from MSAccess to mySQL. The program works by calling external database utility programs which redirect data to and from files using the shell.
While trying to write the new database backup and recovery functions I got a terrible surprise. It seems the angle brackets do not work when sending a commandline through SHELL function (p.e.):
Shell ("""" & mySQLdumpLocation & """" --defaults-file="""" & confFileLocation & """" nameofthedatabase > """" & backuplocation & """")
This instruction opened a command line window where the mysqldump output could be seen but it did not create the backupfile. When copying the same instruction to a cmd window it worked perfectly.
I noticed after many hours looking for information that changing the ">" keyword to -r made the job.
Now I'm facing the same problem withe the recovery of the backup. In theory I need to use this:
Shell ("""" & mysqlexeLocation & """" --defaults-file="""" & confFileLocation & """" nameofthedatabase < """" & backuplocation & """")
...and no, it does not work. It does nothing. The same instruction copied to cmd window works as expected... and I haven't found a substitute for the "<".
Does anyone know what is happening?
Related
I've been searching through the various forums of pre-2005 trying to find out how to run a shell-based application in the current shell using VBS. Ie, I've opened up a terminal, and want to execute this application (which enters a REPL) and use it using the terminal I'm in - instead, a new command prompt is being opened, defeating the purpose of my idea of a gui-less, (pure) REPL version of this application. This application is GNU Octave.
For their Windows installation, they have a VBS script which (based on a CLI arg) opens either the Octave Dev environment, or just the Octave REPL (using --no-gui). They do this through a VBS script (see below) and so I thought, maybe I can modify this to have it open the Octave REPL in the current shell. Turns out this isn't as easy as I thought... I've found the culprit of my issues to be the wshShell.Run command, but apparently that can only run commands in the background, or as a new process - to be clear, I want to run my application in the current process.
I guess that's a lot of preamble for a simple question: How do I (minorly) modify the below file to open the Octave REPL interactively while maintaining all of the environment variables and other settings that it sets?
' script to run octave in gui/command mode
Set wshShell = CreateObject( "WScript.Shell" )
' get the directory that script resides in
Set fso = CreateObject("Scripting.FileSystemObject")
OctavePath = fso.GetParentFolderName(WScript.ScriptFullName)
' ctavePath is now the root of the install folder, but for msys2,
' OctavePath should be OctavePath/mingw64 or OctavePath/ming32
MSysType = "MSYS"
MSysPath = OctavePath
Set objFSO = CreateObject("Scripting.FileSystemObject")
If objFSO.FileExists(OctavePath & "\mingw64\bin\octave-cli.exe") Then
MSysPath = OctavePath & "\usr"
MSysType = "MINGW64"
OctavePath = OctavePath & "\mingw64"
ElseIf objFSO.FileExists(OctavePath & "\mingw32\bin\octave-cli.exe") Then
MSysPath = OctavePath & "\usr"
MSysType = "MINGW32"
OctavePath = OctavePath & "\mingw32"
End If
' get path as a 8.3 path
Set fo = fso.GetFolder(OctavePath)
OctavePath = fo.ShortPath
Set fo = Nothing
' set up path to ensure octave bin comes first
Set wshSystemEnv = wshShell.Environment( "PROCESS" )
if OctavePath <> MSysPath Then
wshSystemEnv("PATH") = MSysPath & "\bin;" & wshSystemEnv("PATH")
End If
wshSystemEnv("PATH") = OctavePath & "\bin;" & wshSystemEnv("PATH")
wshSystemEnv("MSYSTEM") = MSysType
' set terminal type
wshSystemEnv("TERM") = "cygwin"
wshSystemEnv("GNUTERM") = "wxt"
wshSystemEnv("GS") = "gs.exe"
If wshShell.ExpandEnvironmentStrings("%HOME%") = "%HOME%" Then
Home = wshSystemEnv("USERPROFILE")
Set fo = fso.GetFolder(Home)
wshSystemEnv("HOME") = fo.ShortPath
Set fo = Nothing
End If
' set Qt plugin directory and path
If objFSO.FolderExists(OctavePath & "\qt5\bin") Then
wshSystemEnv("PATH") = OctavePath & "\qt5\bin;" & wshSystemEnv("PATH")
wshSystemEnv("QT_PLUGIN_PATH") = OctavePath & "\qt5\plugins"
Else
wshSystemEnv("QT_PLUGIN_PATH") = OctavePath & "\plugins"
End If
' check args to see if told to run gui or command line
' and build other args to use
GUI_MODE=1
AllArgs = ""
Set wshArgs = WScript.Arguments
For I = 0 to wshArgs.Count - 1
If wshArgs(I) = "--no-gui" Then GUI_MODE=0
AllArgs = AllArgs & " " & chr(34) & wshArgs(I) & chr(34)
Next
' start octave-gui, either with console shown or hidden
If GUI_MODE = 1 then
AllArgs = AllArgs & " " & chr(34) & "--gui" & chr(34)
wshShell.Run chr(34) & OctavePath & "\bin\octave-gui.exe" & Chr(34) & AllArgs, 0
Else
wshShell.Run chr(34) & OctavePath & "\bin\octave-gui.exe" & Chr(34) & AllArgs, 1
End If
' free our objects
Set fso = Nothing
Set wshShell = Nothing
Set wshSystemEnv = Nothing
Set wshArgs = Nothing
Converting my comments to an answer, even though I'm still a bit confused what you're actually after, but hopefully it will be covered below ...
For what it's worth, my understanding is that the vbs script is basically a wrapper to the actual octave binary, which should be installed in the bin folder of your octave root directory. So launching the repl should be as simple as putting that directory in your path and typing octave in the console.
I don't know if the windows binaries have more differences, but in the linux binaries, you have octave and octave-cli, where the latter:
octave-cli has been compiled without any GUI support (Qt) which makes it smaller than the default octave executable, but also limits it to providing just the command line interface (CLI).
A crucial difference is that it's missing qt libraries, as you say. If you try to plot within the cli environment, you'll still get graphical windows, but they'll use either the fltk or gnuplot environments instead of qt.
But other than that, you can totally use the normal octave executable which supports qt, and use it in REPL (i.e. --no-gui) mode instead of the full gui. In fact, in linux at least, that is the default behaviour as far as I'm aware; you need to explicitly pass the --gui option to launch the actual gui. Perhaps the developers felt that the windows crowd might find that confusing, so they reversed this behaviour and created octave-gui and octave executables, with the latter essentially being the stripped-down cli version; I don't know. If that is the case, I'm assuming you can use the octave-gui executable and pass some sort of option (presumably --no-gui or something similar) to run it in the console, but still with full qt support for plots etc.
Regarding loading a bunch of unrelated environmental variables of interest to you into your session, there's nothing stopping you from loading these from within octave (e.g. using setenv). Equally, if you want normal 'octave' variables to be predefined on startup, you can put them in your .octaverc file (you can put the setenv declarations there too, I guess). I don't understand why you'd lose plot features if you didn't load "additional" plugins (unless you're referring to the distinction between octave and octave-cli binaries I mentioned above). As long as it's not required for startup specifically, then you should be able to set environmental variables from within octave at any time without problems.
To attach to a existing console a console program must be started by a program attached to that console.
For a program started by a GUI program
If a console program will be given a new console.
If a GUI program it will not be given a console, however it can use AttachConsole API call to attach to any console.
VBScript cannot call API calls.
we have this vbs script we use to update certain documents with SyncToy.
This is the script as it is currently written:
'--------------------------------------------------
Set oShell = CreateObject("WScript.Shell")
sFilePath = chr(34) & "C:\Program Files\SyncToy 2.1\SyncToyCmd.exe" &
chr(34) & "-R"
iRC = oShell.Run(sFilePath, 0, True)
' Return with the same errorlevel as the batch file had
Wscript.Quit iRC
'---------------------------------------------------
I didn't write this script, and I have very little experience with scripting.
I have a task set up in task scheduler that runs this script anytime the device connects to a network. The script should run SyncToy and then synchronize the folder pair that is set up. I have tried running the script through command prompt with the cscript command but nothing happens as far as I can tell. At least the folders aren't syncing.
The script is running on a Windows 10 pro tablet
I have verified that the task is indeed running when it is supposed to. I'm just not sure if it is an issue with the way the script is written or if the task settings need to be changed. Is there anything wrong with the script as far as you can tell?
I was unsure whether to post this here or over in serverfault. If this doesn't belong here please move the question over to serverfault
Update: I've verified that this isn't a problem with the script. This problem apparently arose only after the update from SyncToy 2.0 to 2.1.
Thanks Guys.
There is a error with the sFilePath lines.
First, I don't know if this was originaly on a single line but it should (or add "_" before changing line).
Then, this (...)& >"-R" would not work. The ">" symbole is outside the quotes and generate a error.
If you want to execute this command: "C:\Program Files\SyncToy 2.1\SyncToyCmd.exe" -R,
this is the way to do this:
sFilePath = chr(34) & "C:\Program Files\SyncToy 2.1\SyncToyCmd.exe" & chr(34) & " -R"
You can also add msgbox sFilePath to show a popup with the value of sFilePath.
To test/run the script, you just need to double-click on it.
I am having a heck of a time getting some syntax correct here.
I have a small VB Script which prompts for credentials and then uses those credentials to run another vb script:
set objShell = WScript.CreateObject("WScript.Shell")
strAdminName = inputBox("What is your username (Domain\Username)")
objShell.Run "runas /user:" & strAdminName & " ""Wscript.exe \\xxx.xx.xxx\dfs\Tumw-IS\Juniper Tools and Utilities\Juniper Removal Tools\delete_folders.vbs"" "
When I run the script everything works, except it can't find the script I am calling. I get an error stating "There is no file extension in "\xxx.xx.xxx\dfs\tumw-is\Juniper"
Obviously the problem is in the fact that there are spaces in the file location and also that I am using a DFS link. When I run this and target a VBS file with no spaces in the location it works fine.
I just can't get the syntax down to handle the DFS link or the spaces in the name. I assume it's pretty straightforward, but I just can't get it to work.
Any ideas?
Thanks
-John
Try this:
objShell.Run "runas /user:" & strAdminName & " ""Wscript.exe \""\\xxx.xx.xxx\dfs\Tumw-IS\Juniper Tools and Utilities\Juniper Removal Tools\delete_folders.vbs\"""""
well basically I have a bit of a problem and I'm at a block at the moment, I'm trying to use vbs to run a foxpro .prg file , normally I would have to right click the .prg then click run then foxpro ask me for the possessing date and stuff but i can use sendkeys for that i figured I don't mind if its not hidden any help will be greatly appreciated , thanks
If you can double-click the PRG file and it opens in FoxPro (meaning the PRG extension has a shell association with the FoxPro executable) then you should be able to use the Run method of VBScript's Shell object to "launch" the PRF file directly:
CreateObject("WScript.Shell").Run Chr(34) & strPathToPrgFile & Chr(34)
Otherwise, you could always launch FoxPro and pass the PRG file as a param:
CreateObject("WScript.Shell").Run Chr(34) & strPathToFoxProExe & Chr(34) & " " & Chr(34) & strPathToPrgFile & Chr(34)
I have created a vbs file that calls a batch file which works perfectly when run manually.
When I run the same vbs script from the scheduled tasks, however, the vbs completes without error but it seems the batch file is not called because none of the taks it is responsible for are done.
I have made sure that the scheduled task runs under my administrator account. I have had quite a lot of experience running this same taks on an older server but I have recently migrated to a new 2008 R2 from 2003.
Here is the line that does not execute:
wshell.run "%comspec% /c ""C:\My Scripts\ForAdministration\AddSitesScripts\AddSite.bat"" " & DomainName & " " & WebsiteID & " " & DomainName20 & " " & Path & " " & HasStats & " " & NewAppPool & " " & 1 & " " & 1 & " " & 1, 0, True
I log all of the variables to a text file and they are fine. As i said this runs fine when triggered manually.
Thanks for your help!
Your 2008 R2 machine is a 64 bit system, and %comspec% specifies the 64 bit version of CMD.exe.
Most likely you want to use the 32 bit version of CMD.exe (YES, there are two!).
Change %comspec% to
%SystemRoot%\sysWOW64\cmd.exe
Yes... that is right! The CMD.exe in sysWOW64 is the 32 bit version!
Probably being run as a different user in a scheduled task.
Verify that the user has the necessary permissions.
Verify that the problem is not due to an assumed current directory.
Put the following statement as the first line in the bat file and try running both ways (manual and scheduled):
echo.CD=%cd% & pause
Note that the current directory gets change when you 'Run as administrator'. You can resolve that by adding the following line at the top of your program (to set the desired CD before referencing any files/folders).
pushd %~dp0