Editor's note: This is the 18th column in a continuing series on scripting that appears monthly on SearchWinComputing.com....
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
Feel free to send any scripting questions to the author, Christa Anderson, at firstname.lastname@example.org.
In the July 2006 Scripting School column, we created a script that could serve as a tool for performing an office inventory. But the script had one major flaw: It couldn't vet the information to it.
For instance, while you can't ensure that users supplying their office number or serial number typed the right number, it would be nice if you could tell if they'd typed in something, well, colorful. . .preferably before you needed that inventory information.
Some of you have emailed me looking for ways to find and replace text using VBScript. In my Scripting School columns, we've done a fair amount of pattern matching, using operators to determine which strings (or parts of a string) matched each other and then performing actions based on those results, such as mapping a drive or replacing the string with another string.
In this month's column, I'd like to introduce you to another kind of pattern matching, called regular expressions. Using regular expressions, we can validate user input, find and replace text, and find important strings in ways not possible with other VBScript-supported pattern matching.
Regular expressions were originally part of Unix, used in functions such as the grep command-line search tool. Regular expressions in VBScript can find strings and either replace them or collect them. Regular expressions are represented by an object that perpetually exists in the operating system. Because this object, which has the properties and methods described in the table below, perpetually exists in the OS, you don't need to create an instance for it as you do for WshShell -- just assign it a variable so you can work with it.
|Global||Determines whether the search should return all matching occurrences in the search string (True), or just the first match (False). The default is False.|
|IgnoreCase||Determines whether the search is case-sensitive (False) or not (True). The default is False.|
|Pattern||This required property defines the search expression. This property has no default value.|
|Test||Searches for the search expression defined in the Pattern property and returns True if the string was found and False if it was not.|
|Execute||Executes the search against the value of the Pattern property and returns the results to a Matches collection. Each return value is a Match object.|
|Replace||Finds the search expression defined in the Pattern property and replaces it with the second string provided to the method. If the first string isn't found, then nothing will be replaced.|
If you're using the Execute method to retrieve set strings, these results will be stored in the Matches collection, with each instance being a Match object. Each Match object has the following read-only properties:
- FirstIndex contains the match's position within the original search string, counting from 0.
- Length contains the match's length
- Value contains the actual match, whether that's T or 12 or "my dog is brown."
For example, you could use regular expressions to evaluate input in order to make sure it was a whole number, take that input from the Matches collection, retrieve it using its FirstIndex property, and make sure the input was as long as expected. If it is, great—at least someone's gone to the trouble of making sure that their input follows the accepted format. If it's not, you can prompt them to re-enter the input. After a few iterations, they'll give in and give you what you want!
Tuning the search
Three properties? Three methods? Only three properties for the matches? Bring it on!
If using regular expressions were that easy, this column would have discussed them long ago. VBScript regular expressions can't do everything that the Unix ones can, but the good news is they can do quite a bit. The bad news is that their power makes formatting your queries more complicated than "find the word 'dog' in the files stored in servershare." You'll need special characters in your search expression.
If you've just clicked the above link, you'll realize with a single glance that formatting the search expressions can take a heck of a lot of practice. Hence the utility of the Test method. We'll spend some time on examples to show you how to use these settings.
Uses for regular expressions
So what can we do with regular expressions? First of all, we can validate user input. At the start of this column, we mentioned that the inventory tool we built in July couldn't verify that users were entering a valid office number and computer serial number. Using regular expressions, we can do both—at least enough to ensure that the input follows the expected format. (Next month, we'll discuss how to do this.)
You can also use regular expressions in the following scenarios:
- Finding email addresses in a file and collecting them into the Matches collection object. Once you've got the addresses, you can exploit them in another part of the script.
- Replacing paths in a script—for example, if you've changed a printer name for a particular group, or the home directory paths have changed to a new server.
- Finding and replacing text. You've probably seen how some companies list email addresses on the external Web sites as user (at) somecompany.com, instead of email@example.com. Using the Replace method, you could search for the @ signs and replace them with (at).
So far, we've been able to read and write strings, and assign input to variables, but not check the strings for their formatting. Regular expressions gives us the ability to do that. Although they're not simple, they're much like command-line parameters: If you practice a bit they get easier to use. We'll start doing that next month by revisiting our inventory tool and improving it a bit.
ABOUT THE AUTHOR:
When Christa Anderson began working with Windows Server operating systems in 1992, she became increasingly interested in finding more efficient and flexible ways of performing routine tasks. Christa has written extensively about administrative scripting and taught technical sessions on the subject at conferences such as Comdex and CeBIT, helping people who had never done any scripting to write their own scripts in half a day. In addition to her interest in scripting Windows management, Christa is an authority on server-based computing and the program manager for Terminal Services licensing in Longhorn. If you have a scripting question for Christa, please e-mail her at editor@SearchWincomputing.com.