Multilingual Matters
With the introduction of WSH 2.0, the power and flexibility of scripting using a variety of languages is yours.
- By Chris Brooke
- December 01, 2001
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.