Windows Script Host-to-Batch File Cross-Reference

[chuckhenry]

Is there such a thing as a good cross-reference between Windows Script Host commands and what's available with good ole' DOS Batch files and DOS commands?

I have several fairly lengthy DOS-based batch files (that perform simple tasks) that I've created over the years, but every thing I've read so far with regard to WSH fails to simply correlate between what I've done in the past with Batch files and how I can accomplish those same tasks with WSH. And I'm getting really frustrated because it seems like just about everything I've read so re: WSH goes into a bunch of complexities like ProdIDs, CLSIDs, Referencing Type Libraries, Including External Files, Classes... UGHHH! A simple, grade-school primer, please.

Would appreciate any help. TIA, Chuck

 

[chuckster1]

When I have a good old batch file that does the job I use it often in conjuction with Vbscript.

Set myShell = wscript.createObject("wscript.shell&quot

myShell.run "c:\BatchFile.bat"

or

oProcess = myShell.Run("xcopy blah blah", 1, True)
and the script monitors the process of the batch job and won't continue until the batch job has completed.

That way you can use the more advanced and neater code of vbscript with its subs, objects and arrays etc and embed dos commands in the script.

Hope that helps.

 

[dilettante]

VBScript is more of a programming language than a simple batch control language.

BAT/CMD files are pretty limited to running programs or shell commands, doing a few things conditionally based upon file presence or result values, and so on. Still, people accomplish amazing things using BAT/CMD fles.

They were really intended to "automate" stuff you'd otherwise type in manually step by step though.

This sort of fell apart as tools got complex enough that it was hard to control them through command-line options. What happened then was to adapt the scripting engines developed for other purposes to perform routine administrative activities. This meant component-izing and exposing the programming models of many tools, including even many applications. That was supplemented by stuff like the FileSystemObject and the WShell object (among many others now), and wrapped up in a script engine host (actually 2) called WScript and CScript.

I've heard many a box-jocky complain about having to become a programmer now. One real whiner was the guy at DesktopEngineer.com - but I think he got religion and bit the bullet.

I can sympathize with you - picking up the VBScript programming and understanding how to use the fundamental WSH objects is tough enough. Then you start looking at WMI and remote scripting, and the rest of the goodies made available by MS to "help" the poor "network administrator" and - well, it gets a bit intimidating at times.

But it is sort of like those old-timey shade tree mechanics whining about modern automotive hardware... and software. The stuff has grown up, and grown up pretty ugly. Not much we can do to turn back the clock.