Encoding for the Masses
No matter your job (or platform), scripting makes life easier.
- By Chris Brooke
- May 01, 2003
It can be argued that the primary purpose of application development
in general, and scripting in particular, is to automate repetitive processes—with
a particular emphasis on simplifying the user’s experience. With that
in mind, let’s flex our new developer muscles and look at last month’s
script. What’s wrong with it? (Go easy on me!) Its fundamental flaw is
that it only encodes one script at a time—and only .WSF scripts, at that.
Not very automated, is it? Let’s see what we can do about that.
This script encodes an entire folder of scripts
This script encodes
a folder of scripts
/Source: [Source Folder]
path and name of the folder containing the scripts
helpstring="The path and name of the
folder where the
encoded scripts will
Dim objSourceFolder, objDestFolder,
objFile, objStream, objEncFile
Dim strSourceFolder, strDestFolder,
strSourceFile, strEncFile, strDestFile
Dim strExt, strScriptType
the command-line arguments
the folder and get the collection of files
Then Set objSourceFolder=objFSO.GetFolder(strSourceFolder)
WScript.Echo "Source Folder Specified does
Dest folder does not exist, create it
Loop - Cycle through the source folder
Each objFile in objSourceFolder.Files
Case strExt 'REF: 1
strScriptType <> "NS" Then
the file and read it into a buffer
"Now encoding: " & objFile.Name
the encoded file in the correct format
Len(objFile.Name)-3) & "vbe"
Len(objFile.Name)-2) & "jse"
"Now Writing encoded file: " & objDest
& "\" & strDestFile
"Skipping file: " & objFile.Name
Now That's More Like It!
Geez! We’re thinking like developers now, aren’t we? I’ve taken the code
that encrypts the script and added the capability of encoding an entire
directory of scripts—even if that directory contains different types of
scripts such as .VBS, .JS and .WSF. Furthermore, it ignores any files
that aren’t scripts, just in case you like to keep Readme files or other
assorted documentation in your scripts directory.
I used the FileSystemObject (FSO) extensively to bind to both the source
and destination folders, cycle through each file in the source folder
(encoding any scripts as I find them), and then write those files to the
destination folder. I’ve also programmed the script to keep you informed
about what it’s doing—whether it’s encoding a file, writing that file
to the destination folder or skipping it altogether (if it’s not a script).
This is an important step when writing a script to perform repetitive
actions. If the script fails, it helps to know what it was trying to do.
Like a Developer
I just got back from Orlando,
Florida where I was a speaker at a developer conference.
During one of the coffee breaks, I wound up having a
20-minute conversation with a developer—an Enterprise
Java developer—about Perl scripting. Perl scripting!
What do you know? It seems that, regardless of platform
or language preference, there are combination code-monkeys/server-jockeys
If you’re doing any amount of scripting
as part of your daily tasks, then you are (at least
in part) a software developer. My point is this: To
the extent that your job involves software development,
you should try to think like a developer. Every once
in a while, pick up one of the developer journals from
your company’s magazine rack or coffee table and
thumb through it. In particular, look at Web-development
periodicals, as many Web applications are almost entirely
based around script code. Don’t be put off if
some of it seems over your head. Keep plowing through,
and you’re sure to find a nugget or two that will
prove indispensable to your scripting toolkit. Who knows?
In a year or two, you may find yourself putting in a
training request to go to a developer conference!
Lost in the Translation
Sometimes, as a result of formatting this column for publication, the
script listings might show line breaks at incorrect locations. To alleviate
any potential headaches for you, we’ve started publishing the completed
scripts online for download. Not only will this guarantee that you have
a correctly formatted script, it’ll save you a lot of typing! (Download
the script by Clicking Here
or by right-clicking that link, then choosing "Save As..." from
the context menu. Note that this script or any other script may be falsely
recognized as a virus when you download it.)
I’ve also begun to footnote my inline comments in order to try to keep
the lines shorter. Here are the “complete” comments from the two footnoted
comments in the above script labeled REF: 1
and REF: 2.
REF 1: By using a Select…Case statement, you’re able to check for any
valid script file. If the specified file doesn’t match any of your conditions,
set it to “NS” (No Script) and it will be skipped.
REF 2: When you open a file as a Text Stream, you can specify an I/O mode.
In this case, the I/O mode is 1, which means “For Reading.” Since this
is your source file, you don’t want to write to it accidentally and possibly
corrupt an important script.
Remember that you must disable strict XML parsing for any .WSF scripts.
This means getting rid of the <?xml?>
and <>> tags. The encoder
can’t deal with that added pressure! Also, because .WSF files have the
same extension whether they’re encoded or not, it is possible that you
might accidentally try to encode a script in your source directory that’s
already been encoded. Fear not! The encoder won’t “re-encode” a script.
The worst that’ll happen is that the filename will have two prefixes (for
example, “eeScript.wsf”). It’ll still run just fine.