Mr. Script

Multilingual Matters

With the introduction of WSH 2.0, the power and flexibility of scripting using a variety of languages is yours.

I speak a little Spanish. Not much, but a little. This is a holdover from a time, years ago, when I worked in an area with a large Latino population. Whenever I was providing training or support to a Spanish-speaking audience, I tried to use mostly Spanish. However, in IT there are certain words that simply don't translate (or perhaps I just didn't know las palabras). As a result, my sessions usually involved switching back and forth from Spanish phrases to English phrases (or even word-to-word switching) in what can only be described as "Spanglish." Ultimately, the message was delivered and han entendido what I was saying.

Three months ago, I discussed the ability of Windows Script Components (WSCs) to utilize code from a variety of scripting languages, allowing you to mix-and-match to your heart's content. We didn't actually create any components using multiple languages, but we could have. What you may not know is that this flexibility isn't limited solely to Script Components. You can leverage this in your scripts, as well.

With the exception of WSCs, our scripts so far have been based on the WSH 1.0 format. Each file contains one script, and the language of that script is specified by the file extension. With the introduction of WSH 2.0, scripts can now be in XML format and contain multiple languages (and multiple jobs). The format is very similar to that of WSCs, except that, unfortunately, there's no wizard to help us create them. But have no fear, I'll guide you through the maze of XML tags and we'll emerge into a world of powerful and flexible scripting. Let's begin.

The Obligatory First Script
As all true code-monkeys know, your first script in any new format is required by law to be "Hello World!" (OK… maybe I made that up, but it's still a good way to get familiar with the format.)

<?xml version="1.0"?>
<job>
   <comment>

   HelloWorld.wsf
   This script uses VBScript and JScript to echo
   "Hello World!" to the screen

   </comment>
   <script language="VBScript">

   <![CDATA[
      'I can use standard VBScript comments here
      WScript.Echo "VBScript says... Hello World!"
   ]]>

   </script>
   <script language="JScript">

   <![CDATA[
      // I must use Jscript-style comments here
      WScript.Echo("JScript says... Hello World!")
   ]]>

   </script>
</job>

A Closer Look (From Top to Bottom)

<?xml version="1.0"?>
As with WSCs, this tag is optional and causes the XML to be strictly interpreted. Using it also requires us to include the <[CDATA[…]]> tag in our <script> section (see October 2001's article, "Behold the Power!" for a detailed explanation of what this tag does).

<job>
This is a required element. Essentially, it tells the script host, "This is the job I want you to perform." You can have multiple jobs in a script, each identified by a job id tag: <job id="jobID">. If no JobID is specified, none is required when running the script. However, as you'll see in a minute, scripts with multiple jobs are handled a bit different.

<comment>
This tag allows you to enter a block comment at the beginning of your job. You can also continue to comment your code inside the <script> tags the same as you always have.

<script>
As with WSCs, this identifies the actual script code and is also where the scripting language is specified.

A Word on Color
For several months, I've been color-coding my scripts similar to the way they would appear in a code editor—comments in green, keywords in blue and so on. Because .WSF files are XML files and may be viewed in an XML editor, I've used the colors that would be displayed in most XML editors by default—tags in blue, script code in dark red. One exception to this is that I've kept the actual comments in green (which XML editors don't do). I've kept it this way because comments are important and need to stand out from your code.

The ability to use more than one language in your scripts is only one advantage of using WSH 2.0 scripts. Another feature is that you can break your scripts into several jobs, each containing discrete code you can execute either individually or as a batch-in any order you like. Let's modify our "Hello World!" script to contain multiple jobs.

<?xml version="1.0"?>
<package>
   <comment>
   HelloGoodbye.wsf
   This script uses both VBScript and JScript to echo
   "Hello World!" to the screen. It also uses a second
   job to echo "Goodbye World!" to the screen

   </comment>
   <job id=
"Hello">
      <script language=
"VBScript">
      <![CDATA[
         WScript.Echo "VBScript says... Hello World!"
      ]]>

      </script>
      <script language=
"JScript">
      <![CDATA[
         WScript.Echo("JScript says... Hello World!")
      ]]>

      </script>
   </job>
   <job id=
"Goodbye">
      <script language=
"VBScript">
      <![CDATA[
         WScript.Echo "VBScript says... Goodbye World!"
      ]]>

      </script>
      <script language=
"JScript">
      <![CDATA[
         WScript.Echo("JScript says... Goodbye World!")
      ]]>

      </script>
   </job>
</package>

In this script I've created another job. Having done this, I'm required to define each job with a JobID. I've also introduced the <package> tag, which is required if your script has more than one job.

"R2, fire up the converters!"
Running WSF files can be accomplished a number of ways. First, you can simply double-click on the .WSF file. This causes the script to be run using WScript.exe, which, as you know, causes all output to be displayed in message boxes. Each time text is displayed, you have to click <OK> to continue.

You can also run these files from the command line using cscript.exe. This method allows you to specify the job or jobs you want to run.

C:\cscript //job:hello HelloGoodbye.wsf

If no job is specified, CScript.exe simply runs the first job. You can run multiple jobs, in any order, by listing them individually.

C:\cscript //job:goodbye //job:hello HelloGoodbye.wsf

The //job flag can also be specified after the .WSF file.

C:\cscript HelloGoodbye.wsf //job:hello //job:goodbye

Homework
For your homework, I want you to create a .WSF file that contains several jobs, with each job performing a unique administrative task.

Adios.

About the Author

Chris Brooke, MCSE, is a contributing editor for Redmond magazine and director of enterprise technology for ComponentSource. He specializes in development, integration services and network/Internet administration. Send questions or your favorite scripts to [email protected].

Featured

comments powered by Disqus

Subscribe on YouTube