All Forums >> [Scripting] >> WSH & Client Side VBScript >> Import bat file echo response into vb wscript.echo ?? Do you like VisualBasicScript.com? Link to us and help spread the word about our forum. Thanks!
I have the following code (basic I know) which tells us the dates these files were created as these files update pick lists in our in house software.
What I would like to know, is......We have a bat file that echos a version number of the software....is there any way I could find the version number by running the batch file silently with vb and exporting the result to wscript echo ?
Yes you could do that. Before we discuss that however, you only need one FileSystemObject not six of them.
To get the output of the bat file you can do one of two things. You can use the .Run method to run it completely silently and pipe the output of the bat to a text file then read the text file with your script to get the result. Alternatively you could use the .Exec method which would give you direct access to the STDOUT of the bat file, but there would be a visible DOS box with this method. Both methods have many examples in this forum.
Sorry for been nieve but how do I get it to work rather than have 6 FileSystemObject. I tried it with one but it didnt seem to work and it was a simple work around.
I used the > to export the batch file to a text fille, I just need to import it to my wscript.echo now. I will try and do it and get back with the results
So first, the single FileSystemObject issue. Here is the code:
Set filesys = CreateObject("Scripting.FileSystemObject") Set demofile1 = filesys.GetFile("C:\MService\dbase\DSY_iPICKLIST") createdate1 = demofile1.DateCreated Set demofile2 = filesys.GetFile("C:\MService\dbase\DSY_iTASKLIST")
...etc
As for getting the output of the bat file, you can use that same FileSystemObject. Search the forum for .Read() or .ReadAll().
Maybe we need to understand your problem better. When I do what JP says, the entire file is slurped into a variable and a single echo statement outputs the entire file as one string. Is this not what you want? Do you want the carriage returns removed? If so then use the Replace() function.
That's what I get, whether I run the script so it gets parsed by wscript (in which case the string comes out in one single Windows dialogue box) or by running it from a DOS box with cscript (with which the output comes through in one big rush). The seperate lines are still there of course, but then why would anyone want them not to be?
I thought the behaviour experienced by the OP might just be due to the ForReading constant being set to '8' (append) instead of '1' (read only) - not that there's any reason for it to do that especially as when I had ForReading set to 8 the script would fail at the 'strText = objTextFile.ReadAll' line anyway!
Yours, puzzled.
_____________________________
JJ
Variables won't. Constants aren't Apostrophes do not belong in plurals of anything, especially not acronyms like HDD, PC, CPU and so on
Thanks for your help. JJ I think it was the text file that I was having problems with when trying to extract the text file data to wscript.echo.
Below is my full script. Please could you cast your eye over it and offer your knowledge as I am still raw. It does all that I want, so I am happy with that but I would like to know where I could improve for next time.
Thanks
Martyn
Dim filesys,oFilesys, oFiletxt, sFilename, sPath 'Write the batch file to how we want it for Version.bat Set oFilesys = CreateObject("Scripting.FileSystemObject") Set oFiletxt = oFilesys.CreateTextFile("C:\MService\Version.bat", True) sPath = oFilesys.GetAbsolutePathName("C:\MService\Version.bat") sFilename = oFilesys.GetFileName(sPath) oFiletxt.WriteLine("@echo off") oFiletxt.WriteLine("setlocal") oFiletxt.WriteLine("call C:\mservice\SetEnv.bat") oFiletxt.WriteLine("%JVM% system21.mservice.Version %*") oFiletxt.WriteLine("%JVM% system21.mservice.Version %* > MService_Version.txt") oFiletxt.WriteLine("pause") oFiletxt.WriteLine("endlocal") oFiletxt.Close' Set objShell = WScript.CreateObject("WScript.Shell") objShell.Run("%comspec% /c c:\mservice\version.bat"), 0, False wscript.sleep 500 'Start of the finding the PickLists Last Modified Date Set filesys = CreateObject("Scripting.FileSystemObject") 'Client Side Set demofile1 = filesys.GetFile("C:\MService\dbase\DSY_iPICKLIST") createdate1 = demofile1.DateLastModified Set demofile2 = filesys.GetFile("C:\MService\dbase\DSY_iTASKLIST") createdate2 = demofile2.DateLastModified Set demofile3 = filesys.GetFile("C:\MService\dbase\DSY_iSAFETYCHECK") createdate3 = demofile3.DateLastModified Set demofile4 = filesys.GetFile("C:\MService\dbase\DSY_PICKLIST") createdate4 = demofile4.DateLastModified Set demofile5 = filesys.GetFile("C:\MService\dbase\DSY_SAFETYCHECK") createdate5 = demofile5.DateLastModified Set demofile6 = filesys.GetFile("C:\MService\dbase\DSY_TASKLIST") createdate6 = demofile6.DateLastModified 'Server Side Set demofile7 = filesys.GetFile("\\itdept01\systems\Picklistfiles_FM\DSY_iPICKLIST") createdate7 = demofile7.DateLastModified Set demofile8 = filesys.GetFile("\\itdept01\systems\Picklistfiles_FM\DSY_iTASKLIST") createdate8 = demofile8.DateLastModified Set demofile9 = filesys.GetFile("\\itdept01\systems\Picklistfiles_FM\DSY_iSAFETYCHECK") createdate9 = demofile9.DateLastModified Set demofile10 = filesys.GetFile("\\itdept01\systems\Picklistfiles_FM\DSY_PICKLIST") createdate10 = demofile10.DateLastModified Set demofile11 = filesys.GetFile("\\itdept01\systems\Picklistfiles_FM\DSY_SAFETYCHECK") createdate11 = demofile11.DateLastModified Set demofile12 = filesys.GetFile("\\itdept01\systems\Picklistfiles_FM\DSY_TASKLIST") createdate12 = demofile12.DateLastModified 'Extracting the MService Version Const ForReading = 1 Const strFile = "C:\MService\MService_Version.txt" Set objFSO = CreateObject("Scripting.FileSystemObject") if objFSO.FileExists(strFile) then Set objTextFile = objFSO.OpenTextFile (strFile, ForReading) strText = objTextFile.ReadAll objTextFile.Close
Else Wscript.Echo "File " & strFile & " doesn't exist...!" End If 'Echoing out the Version and PickList Dates been used
Well, like ebgreen said, you only need to define the FileSystemObject once.
It's a good habit to close off the objects at the end of your script like this:
Indentation is your friend. Use it! (Witness the If...ElseIf...End If loop and the wscript.echo at the end).
'Option Explicit' is also your friend as it forces you to define all your variable names and in so doing cut out issues caused by typing errors. Make it the first line of all your scripts. It can make troubleshooting a LOT easier!
Hardcoding filenames works, but, what a pain should you need to change them later on! I'd suggest putting the target filenames in a couple of text files and reading the contents of each in to arrays in the VB the script.
Text File 1 'Client_Side.txt' C:\MService\dbase\DSY_iPICKLIST C:\MService\dbase\DSY_iTASKLIST C:\MService\dbase\DSY_iSAFETYCHECK C:\MService\dbase\DSY_PICKLIST C:\MService\dbase\DSY_SAFETYCHECK C:\MService\dbase\DSY_TASKLIST
Text File 1 'Server_Side.txt' \\itdept01\systems\Picklistfiles_FM\DSY_iPICKLIST \\itdept01\systems\Picklistfiles_FM\DSY_iTASKLIST \\itdept01\systems\Picklistfiles_FM\DSY_iSAFETYCHECK \\itdept01\systems\Picklistfiles_FM\DSY_PICKLIST \\itdept01\systems\Picklistfiles_FM\DSY_SAFETYCHECK \\itdept01\systems\Picklistfiles_FM\DSY_TASKLIST
And then for repetitive sections such as Set demofile1 = filesys.GetFile("C:\MService\dbase\DSY_iPICKLIST") createdate1 = demofile1.DateLastModified Set demofile2 = filesys.GetFile("C:\MService\dbase\DSY_iTASKLIST") createdate2 = demofile2.DateLastModified Set demofile3 = filesys.GetFile("C:\MService\dbase\DSY_iSAFETYCHECK") createdate3 = demofile3.DateLastModified etc. create a subroutine and get it to do the work for you with the data read in from those two text files. That way should the number of files that require checking reduce or increase all you have to do is edit the two input files.
Here's my finished version of the script (I could have done more, like save the report in text file and open that, or in a .html file and open it in Internet Explorer, or a .csv file, or even an Excel Workbook, and it should probably have better error trapping, we could have used named arguments, one text file instead of two text files and so on, but I really should get back to my own scripts!)...
Of course, I don't claim this is THE best way of doing it. If someone like ebgreen notices any glaring stupid code in there I hope they won't be shy in politely pointing out a better way. It's all a learning experience...
_____________________________
JJ
Variables won't. Constants aren't Apostrophes do not belong in plurals of anything, especially not acronyms like HDD, PC, CPU and so on
Well, functionality is king for scripting languages, so if it works then by definition it is right. I will add some of my best practices tips:
Using Call...I can't think of any reason to use the Call keyword. All it does is execute a function and discard the return value. If your don't want to use the return value then don't write the routine to send one back, or just don't catch it. Regardless Call doesn't do anything for you.
While Count is not a reserved keyword, it is a very common property name so I think I would avoid it as a variable name. Simply using proper hungarian naming would avoid any confusion, so I would change it to nCount.
I would do checkengine as pretty much the first thing. No point to doing anything else if we are just going to exit anyway.
I like keeping scope as small as possible, so if you only use a variable in a sub, then you should only dim it in that sub.
Along with that I am a fan of keeping coupling as lose as possible. So for instance in the CheckEngine sub, you are using the objShell object that you declared globally. This decreases the reusability of the code. It means that if you wanted to reuse the Checkengine Sub in another script, you can't just drop it in the script and call it. You have to make sure that you declare a global objShell in the other script too. Better is to have the sub be conpletely self contained.
objClientFile and objServerFile are declared but never used so I just took them out.
You create strFileName and assign a value to it, but you never actually do anything with that value, so I just took it out. Same with strPath.
strServerFileDates is never used so I took it out. Same for strClientFileDates. And strInputFile.
The GetModifiedDate Sub relys on the global strCreateDates variable. Again, this indreases coupling which is a bad thing. A better solution is to change the Sub to a Function (and with a name that starts with the Get verb, it shouold be a function that returns something anyway) and have it return the string.
strPCEngine should be scoped to the CheckEngine Sub only.
General naming conventions hold that constants should be written in all caps so I changed sBatchFile to BATCHFILENAME
I did all these changes but I didn't run the script so I may have introduced some typos. Here is what I came up with:
Using Call...I can't think of any reason to use the Call keyword
Where I'd used it there's certainly no reason. Not even sure why I did.
quote:
While Count is not a reserved keyword, it is a very common property name
Granted. And besides it's just not consistent to just call it 'Count' instead of with a prefix of some kind. Never heard it called Hungarian naming though. Nice.
quote:
I would do checkengine as pretty much the first thing... for instance in the CheckEngine sub, you are using the objShell object that you declared globally
It had never occurred to me to declare an object twice, albeit once contained within a sub to avoid duplication, hence my entries for CheckEngine always appear a little further in than felt right to me. Good advice,ebg, I like it.
quote:
I like keeping scope as small as possible, so if you only use a variable in a sub, then you should only dim it in that sub
I think I tend to declare everything at the top because I often change my mind about whether a variable will be used only in a sub or globally. I guess the default position should be to use them in subs unless there's good reason for global declarations. I'll try to remember that.
quote:
objClientFile and objServerFile are declared but never used so I just took them out... strServerFileDates is never used so I took it out. Same for strClientFileDates. And strInputFile
Victims of Work In progress I'm afraid. They were used during development but changed later when I decided the approach I was working on was inappropriate or just plain wrong...
quote:
You create strFileName and assign a value to it, but you never actually do anything with that value, so I just took it out. Same with strPath
For these I firmly point the accusing finger at the original poster. "It wuz 'is code, M'lud!"
quote:
change the Sub to a Function (and with a name that starts with the Get verb, it shouold be a function that returns something anyway) and have it return the string
As my boss says, "The easiest decision to make is not to make a decision at all...". These kinds of rule help decide what to call functions and I like that.
quote:
General naming conventions hold that constants should be written in all caps so I changed sBatchFile to BATCHFILENAME
That's a new convention on me (which doesn't mean I think you're wrong, BTW!) but I'm not sure I like this one. Still, when I played Dungeons and Dragons (over 20 years ago! I was young! Give me a break!) I almost always played Lawful characters which I guess is a reflection of my own character so I expect I'll adopt this one too (although I've always gone for the 'con' or 'const' prefix instead. Perhaps I'll go for an amalgam of constBATCHFILENAME instead just to satisfy what few rebellious traits I have).
_____________________________
JJ
Variables won't. Constants aren't Apostrophes do not belong in plurals of anything, especially not acronyms like HDD, PC, CPU and so on
Just be sure to realize that none of that was criticism. Those were just all things that I have come to over years of coding. A lot of my time has been as a maintenance code trying to understand other people's code, so my best practices are often geared toward making code more maintainable. For most of those points you could probably find someone here with a perfectly valid counter-argument.
All Forums >> [Scripting] >> WSH & Client Side VBScript >> Import bat file echo response into vb wscript.echo ?? 
Printable Version
Import bat file echo response into vb wscript.echo ?? - 
