[#winscrho]:

Windows Scripting Host

For more details about the name of this product, its discontinued status, the name (Windows Scripting Host compared to Windows Script Host), WSH's interactions with multiple scripting engines, see Windows Scripting Host (overview) (which is a section on the page about scripting languages).

Code samples
Interacting with text files

This may not have been tested recently (especially the JavaScript, which may be fully untested at the time of this writing).

This process ends up using an object called a FileSystemObject. Some documentation for Visual Basic indicates that FileSystemObject handles only text files, and not binary files. This code does involve using an object's method that is called OpenTextFile which also suggests that this method might not work for binary files.

Declarations
Using Constants
const ciForReading=1
const ciForWriting=2
const ciForAppending=8

(Note: The above example may work identically in both JavaScript and VBScript. Recommended JavaScript style would say that there should be a semi-colon at the end of each of those lines. However, it isn't strictly necessary. By not using the semi-colons, the code was able to be made identical for both JavaScript and VBScript.)

JScript

Microsoft JScript might not support “const”. In that case, just use variables instead.

var ciForReading=1
var ciForWriting=2
var ciForAppending=8

Some documentation may refer to constant named values, like a value for the name ciForReading which is set to 1. Those values may not be part of the language specification, so define the names as needed (and make sure that the correct values then get passed to the needed functions). Technet: Visual Basic for Applications Reference: Visual Studio 6.0: OpenTextFile Method shows a value of ForAppending (which this code refers to as ciForAppending) being set to 8, but then the example shows a value of ForAppending being set to 3. DevGuru's page on FileSystemObject.OpenTextFile indicates that 8 is what is used for appending.

A filesystem object will be needed, so reserve a variable name for that purpose. Typically, example documentation of a WSH Filesystem Object ends up having a variable that ends with the letters FSO.

JavaScript
var oFSO;
var oFileObj;
var sFilename;
var sErrorText;
var bBroken;
var oErr;
VBScript
Dim oFSO
Dim oFileObj
Dim sFilename
Dim sErrorText
Dim bBroken
Dim bPreErr
Checking for pre-existing errors

This way, if an error flag was set, then that won't cause later code to treat that as a problem.

VBScript
Warning: Code is currently untested...
If ( Err.Number <> 0 ) Then
bPreErr = true

' Actually, doing nothing else except for just setting that variable
' is probably a terrible way to handle the issue, but this generic
' (example) code does not presume a more specific way to handle the
' problem.  (Details on what is acceptable might
' potentially vary between different programs or code segments.)
' Perhaps a better way is to report the
' pre-existing problem and then run the Err.Clear method/function?
Else
bPreErr = false
End If
JavaScript

Actually, becuase JavaScript's error handling is more localized, this does not need to be a manually performed action. (So, JavaScript is simpler than VBScript in this specific way.)

Prevent Crashing
JavaScript: This will be shown in the code for instantiating the object VBScript: On Error Resume Next
Instantiate a FileSystemObject
First, instantiate a FileSystemObject (and set the newly created object to be the contents of a variable).
JavaScript

To do this in JavaScript:

try {
oFSO = new ActiveXObject("Scripting.FileSystemObject");
}
catch (oErr) {
;
}
catch(oErr {
;
}
VBScript
Set oFSO = CreateObject("Scripting.FileSystemObject")
Check results
JavaScript

JavaScript: (untested)

Right after the “try” statement, use:

catch(oErr)
{
sErrorText = "";
sErrorText = sErrorText + "FileSystemObject could not be instantiated.";
sErrorText = sErrorText + " Attempt was made to open file: " + sFileName;
sErrorText = sErrorText + " Err " + oErr.number;
If ( typeof( oErr ) != "undefined" )
sErrorText = sErrorText + " by " + oErr.source + " : ";
sErrorText = sErrorText + " Desc : " + oErr.description ;
WScript.Echo(sErrorText);
bBroken = true;
}
if(!bBroken)
{
/* Proceed with remaining steps for opening the file */
}
VBScript
Warning: Code is currently untested...
If ( Err.Number <> 0 AND bPreErr = true) Then
sErrorText = ""
sErrorText = sErrorText & "FileSystemObject could not be instantiated."
sErrorText = sErrorText & " Attempt was made to open file: " & sFileName;
sErrorText = sErrorText & " Err " & Err.Number
sErrorText = sErrorText & " by " & Err.Source & " : "
sErrorText = sErrorText & " Desc : " & Err.Description
WScript.Echo sErrorText
bBroken = true
Else If ( Err.Number <> 0 ) Then
' There may have been an error; we have no reliable way to tell.
' To be safe, this will be treated as an error, and so will not
' continue as if the file successfully opened (although the file
' might have actually been opened successfully).  The actual best way
' to handle this situation is to never get into this situation,
' which can be done by making sure that bPreErr
' did not just remain true.  (Instead, handle any pre-existing error
' so that bPreErr may be justifiably false.)
' This code leaves the task of reporting the pre-existing problem,
' so other code may take care of that task.
Else
' Proceed with remaining steps for opening the file
End If
Seeing if the file exists

If the file is going to be read, check if the file exists using oFSO.FileExists(sFileName). If not, then don't bother triggering an error (which may do something like setting a value for Err.Description). Instead, just handle the situation (inform the user, and don't try to open the file.)

If a file is going to be written to, and if the intended/expected output file pre-exists, then there may be multiple approaches that are commonly taken. One may be to ask the user what to do. A more thorough program might first try to check permissions, and then provide a more detailed report to the end user.

Opening the file

This should only happen if there are no problems. This is shown in both languages by an empty block of code (containing a content, but no actual instructions). Please this functionality into that block of code.

The following shows the syntax for reading a file:

JavaScript
try
{
oFileObj = oFSO.OpenTextFile(sFilename,ciForReading,false);
}
VBScript
' Note that the following linemight trigger an error.  However, it is
' safe to act on the premise that On Error Resume Next is still in effect.
Set oFileObj = oFSO.OpenTextFile(sFilename,ciForReading,false)

The above examples show how to open a file for reading. When writing a file, change ciForReading to ciForReading or ciForReading. Also, the third parameter ("false") refers to how to handle the situation if the specified file already exists. If it is set to true, the file will be overwritten. Otherwise, an error will occur.

Check results

Now that there has been an attempt to open the file, see whether or not it was scuccessful. (This example code looks fairly similar to earlier error checking.)

JavaScript

In JavaScript, do this right after the try statement completes (after the right curly brace).

catch(oErr)
{
sErrorText = "";
sErrorText = sErrorText + "The file named " + sFileName + " could not be opened.";
sErrorText = sErrorText + " Err " + oErr.number;
If ( typeof ( oErr.source ) != "undefined" )
sErrorText = sErrorText + " by " + oErr.source + " : ";
sErrorText = sErrorText + " Desc : " + oErr.description ;
WScript.Echo sErrorText;
bBroken = true;
}
if(!bBroken)
{
/* Continue on with interacting with the file */
}
VBScript
If ( Err.Number <> 0 ) Then
sErrorText = ""
sErrorText = sErrorText & "FileSystemObject could not be instantiated."
sErrorText = sErrorText & " Err " & Err.Number
sErrorText = sErrorText & " by " & Err.Source & " : "
sErrorText = sErrorText & " Desc : " & Err.Description
WScript.Echo sErrorText
bBroken = true
Else
' Proceed with remaining steps for opening the file
End If
Interact with the file

At this point, the code is inside of nested conditional branching. So be it. The WSH object provides functions such as Read (to read a character), ReadLine, ReadAll, and WriteLine.

For example, the following is some example JavaScript:

sFileText = oFileObj.ReadAll()

That example depends on multiple things, like the sFileText variable pre-existing, and the file being successfully opened with permission to be able to read from the file. Also, that specific example might not be advisable in some cases, like if the opened file is extremely large. So, do not just blindly copy that example. Instead, perform whatever actions make sense. (Which actions make sense will likely depend on why the file was even being opened.)

Close the file
oFileObj.Close

Yup, JavaScript and VBScript are the same in this regard. There are no necessary differences for this particular step. (Although JavaScript may wish to append the optional semi-colon for consistent style, it is not strictly necessary in this case, and so the exact example code shown works for both VBScript and JavaScript.)

Destroy the FSO
JavaScript
delete oFSO
VBScript
Set oFSO= Nothing
Return to normal error handling

This is entirely unneeded in JavaScript. Even in VBScript, this is an optional step that some people might prefer to not perform. To return error handling back to the default method, run the following in VBScript:

On Error Goto 0

Realize that variations that do less error checking are more likely to be problematic. Problems may include program instability or, perhaps less severe, the program experiencing an error without providing the most detailed error report which is possible. Serve users better by following the above process.

That certainly was quite a few steps. It may often make sense to create a function to perform many of those steps. For example, a writeline command, that is given a filename and content to write, could be made. This function could open a file and appends a line. This could be rightfully scoffed at by coders who recognize that calling writeline would need to create a filesystem object multiple times, which is wasteful. However, it would also makes the calling code a lot easier to read. Whether or not this is an acceptable performance penalty may vary based on the requirements of the project. It is likely best to use such a simplified function if writing just once to multiple different files; if just one main data file is used a lot, then it may make more sense to leave a file open while it gets worked with.

Using libraries
Information about doing this in VBScript is available from the section about VBScript Libraries.
[#wshexec]: Running a command line

Information has been moved to a dedicated sub-section. See: WSHexec.

Executable files

The Windows Scripting Host program may come with multiple executables. At least for VBScript code, the CScript will cause the “WScript.Echo” command to output content to a console session, while the WScript command will send the output to a GUI dialog box. (The fact that the VBScript object's name is WScript and that the name matches the name of the command line program called WScript may simply be coincidental.) The VBScript source code may be identical, and runs differently based on whether the source code is used by CScript or by the command line program called WScript.

MS KB 188135 calls these files “the protected-mode Windows-based host (Wscript.exe), or the real-mode command shell-based host (Cscript.exe).”

Security
MSDN: WSH security
Debuggers

The following options may be designed to work with Internet Explorer:

Internet Explorer Developer Tools
A feature of MS IE 8 and newer, and available as a toolbar for IE 6 and 7. With Internet Explorer 9, the F12 keyboard key might be related to thse tools. (See: MSDN page for IE9 F12 Developer Tools.) Internet Explorer Developer Tools (Microsoft Installer file) for XP/Vista/Windows Server 2003 and MS IE before version 8 (version 6 or version 7).
Microsoft Script Debugger

Works with MS IE and perhaps some other software, such as IIS. See: Wikipedia's page for “Microsoft Script Debugger”

MSE
Included with Office 2003, not 2007

That doesn't present a lot of options for people making programs for the command line.

MS KB Q308364 references a “script debugger” named Msscrdgb.exe, and provides some more information which might only apply to Microsoft Windows Scripting Host 2.5 (or newer versions?)

Command line
Double-slashes

The WSH executables (both CScript.exe and WScript.exe have the fairly unusual characteristic of using double-slashes as the official command line parameters. For instance, typing CScript.exe/? will show command line parameters that start with double-slashes.

That is intentional. A web page, which Microsoft hyperlinks identify as “Using the command-based script host (CScript.exe)” and also the title “Run scripts using the Windows-based script host (CScript.exe)”, describes this. Some “options are always preceded by two slashes (//).” These options are called “host options” and “are the command-line switches that enable or disable various Windows Script Host features.” (This basically refers to all options that are meant to be recognized by the CScript.exe and WScript.exe software, except for the script filename.) Parameters that are meant to be passed onto the script “are always preceded by one slash (/).”

In reality, some experience has indicated that at least some parameters may be interpreted as a host option even if a single slash is used: one of those two slashes seems to be optional.

Using //NoLogo

Using //NoLogo is generally good, unless the user is actually trying to figure out which version of the software is being used. Using this parameter is often not worth the effort of typing the command line parameter, but if this software is going to be run by some sort of automated process, then including //NoLogo is generally a good thing.

[#wshslshe]: Using //E:

Using different scripting engines is how WSH supports multiple different programming languages. Usually the correct programming language is automatically detected by paying attention to the filename extention. However, a specific scripting engine can be specified on the command line parameter. (e.g.: “CScript//E:JScript filename”.)

Wikipedia's article on Windows Script Host lists available engines. VBScript and JScript engines are produced by Microsoft and come with the WSH software (which is bundled in with some operating systems), while other engines for WSH get installed during the process of installing some other software. MVPS: Active Host Engines lists some additional engines.

This topic is also covered a bit by WSH scripting engines.