This example has few arguments and they all appear to be similar kinds of values -- they're all servers. It may...
not matter much which order you enter the server names. Imagine, though, if the arguments discussed different kinds of things:
Mixing up the arguments so that the script got a server's name when it expected a user's name would probably break whatever action you wanted the script to complete. Therefore, the value of the WshNamed collection would be a filtered view of the WshArguments collection that returns only those arguments that conform to a particular syntax.
Which syntax is that? Specifically, all arguments that you want to include in the WshNamed collection consist of a name and a value. The name must be prefaced by a forward slash, and a colon must separate the name from the value. Within this format, you have some freedom, but in order to make the argument recognizable as a named argument, you must use the slash and colon, like this:
Both names and values must be either a single word or enclosed in quotation marks. An argument with no name is an unnamed argument.
The value of named arguments is that your script now has a way of finding the argument that it wants without you needing to hard code its index number into the script at any point. By giving the value a name, you've added another column to the organizational table:
And that means it's no longer as important to you during the course of your script whether the port was supplied as the first argument or the third, so long as you refer to the argument by its name. You can now retrieve the value "BigDog" not just by its index name but by its name, like this:
Wscript.Arguments.Named.Item("server"). Take the following snippet and save it as namedargs.vbs:
From the command prompt, type namedargs.vbs /port:3389 user:FredA /server:FileServ. As you'll see, this script will return exactly the same data, in the same order, regardless of the order in which you supply arguments. This means that running your scripts will require less training because you won't have to emphasize that the arguments must be entered in a particular order. You will still need to educate people about what the correct names are, but names are easier for people to remember than argument order.
Scripting School: Windows Script Host arguments
Background: Arguments in general
The value of named arguments
Supporting optional arguments
Mixing argument types
Read Christa's previous columns:
Beginner's guide to scripting
It's time to increase your scripting expertise
Scripting: Connect users to network resources
Scripting School: More on connecting to network resources
Scripting School: Find objects with Windows Scripting Host
|ABOUT THE AUTHOR:|
| Christa Anderson
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 scripting@SearchWinSystems.com.