An essential tool of system administrators and power users has been the shell script or batch file (depending on your OS). Unix shell scripts offer an unparalleled combination of ease of use and power. DOS batch files were not as easy to use and were missing many of the tools available in Unix, but were still very useful for automating everyday tasks.
However, longtime Microsoft observers will note that each version of Windows has had less power available to batch files than the version before. There is no longer even a way for the user to input a choice to a batch file. Clearly, Microsoft has done this deliberately. Of course, system administrators and power users still clamor for automation tools. Microsoft has responded with the Windows Script Host, which you have on your system if you have Internet Explorer version 5.0 or later installed in Windows. (If you have an earlier version of Internet Explorer, the Windows Script Host is available as a separate download.) Why the transition from batch files to Windows Script Host scripts? In my opinion, it is because Microsoft would rather have you use a technology they invented rather than a technology where they are second best to a rival OS.
That's the good news about the Windows Script Host. The bad news is that all this power comes at a price. The price is that it is quite a bit more difficult to write a Windows Script Host script than a batch file or Unix shell script. To do just about anything worthwhile, a script must use a COM object. While the Windows Script Host completely hides the complex nature of the COM interface so familiar to many Visual C++ programmers successfully, you still are responsible for knowing an object's properties and methods, complete with calling parameters, in order to use the object. For example, in a batch file, to copy a file you might use the command " copy c:\articles\article.txt ..". That was straightforward and intuitive, at least to a programmer used to such things. With the Windows Script Host, you invoke the CopyFile method of the FileSystemObject object. The method's first parameter is the source filename, the second is the destination filename, and the third optional parameter specifies whether an existing file shall be overwritten if found. You must know all this to copy a file, because you don't get any hints.
This becomes rather difficult because when writing a script you must constantly have the documentation open. But what makes it worse is that like any script, you are probably writing it in an ordinary text editor. As far as I know, Visual Studio .NET is the only programming environment that provides specialized tools (IntelliSense, etc.) for editing Windows Script Host script files. Since Visual Studio .NET is an expensive specialized tool for programming, many people won't have it. If you don't have Visual Studio .NET, when you need to debug a script you will likely be forced to resort to the equivalent of putting ECHO statements into the code as a debugging aid. Actually, it's worse than that, because with a ECHO statement, at least you could have the output from several ECHO statements on the screen at once; with the Windows Script Host you must pop up a dialog with an OK button containing your debugging text, and only one dialog can be shown at a time.
Another difficulty is that Windows Script Host scripts typically interact with users by popping up dialogs. If the script is not designed to be run unattended, and your script does something for a long time without popping up a dialog, your users will become restless because there is no indication of anything happening -- not even an hourglass cursor. It is possible to see that your script is still running if you are using Windows NT or a descendent because "wscript.exe" will be in the task list, however.
Once you have mastered the Windows Script Host, you will discover that your script is about 90% as complex as the equivalent C, Delphi, or Visual Basic program doing the same thing. But those other environments are all much richer, because they include specialized editors, integrated debuggers, proper Windows forms, and so on. If you are a typical Windows programmer, you would rather eat nothing but plain white rice the rest of your life than give up your context-sensitive editor, property and method hints, breakpoints, and variable watches. If you have access to any modern advanced programming language with an IDE, spare yourself the trouble and use it instead of the Windows Script Host. Or else re-engineer the old batch file commands now missing such as "choice".