Posted by Greg Stemp. If you read the previous post, it should be obvious that the Scripting Guide didn’t exactly get off to a flying start. Once we got rolling, however, we actually ended up getting way ahead of ourselves. How? Well, the truth is, we started writing the Windows 2003 Scripting Guide way too early. Because we were part of the Windows 2003 Resource Kit and because the Resource Kit was not going to be released until Windows 2003 shipped, we soon had hundreds of scripts lying around, just gathering dust and waiting for Windows 2003.
And so in early 2002, I got what I thought was a brilliant idea: instead of just sitting on these scripts for another year or two, why not post them to the Web? Why not make them available to anyone who wants them? Granted, without any documentation they might be of marginal use to most people but, still, what was the point of us hoarding them when there might be a few people who would find them handy?
And so I went to TechNet and said, “Hey, we have several hundred scripts that can be used to manage Windows computers. Would you guys be interested in posting them and making them available to Microsoft customers?” And the good folks at TechNet took one look at what I had to offer and immediately gave me an answer: “No.”
Of course, as an advocate for Microsoft customers and as a visionary who foresaw how useful and important scripting would become, I fought tooth-and-nail to get the Script Center up and running, right? Uh, well, not exactly. When TechNet said no, I looked them straight in the eye and said, “Oh. OK.” And then I went back to my office and promptly forgot all about it.
Fortunately someone at TechNet was a heckuva lot smarter than I was (ok, fine: everyone at TechNet was a heckuva lot smarter than I was), and he called me back a couple months later and said, “Hey, do you guys still want to do that Script Center thing?” We did, but that also raised an important question. In my usual fashion, I hadn’t actually thought about what the Script Center would look like or what kind of scripts we wanted to put in there; I just set out to get us a Script Center of some kind, assuming that we’d figure out what to do with it when the time came. (Yes, very much like the old joke about dogs who chase cars, and the question over what they would do if they ever actually caught one.) Being remarkably lazy, my suggestion was to just give them the scripts as-is, without doing much beyond ensuring that they actually worked.
You might think that, as the self-proclaimed head Scripting Guy, anytime I made a pronouncement such as that it is met with universal acclaim and unanimous consent. Trust me, it’s not; in fact, we definitely we’re not in agreement on this issue. Why? Well, as I noted yesterday, we Scripting Guys weren’t hired to be scripting guys, we were hired to be technical writers and to write a book on system administration scripting. Because very few system administrators were writing scripts back then, we opted to write a book that was more educational than pure reference. (Yet another idea that did not meet with universal acclaim and unanimous consent. Although we Scripting Guys thought this was the best approach, other people did not; many, in fact, wanted us to just put together an alphabetical list of VBScript functions and call that a Scripting Guide.) At any rate, keeping in tune with our educational approach, we kept our scripts simple and to the point; we didn’t include error handling, we didn’t include command-line switches, we didn’t comment each part of the script, etc., etc. Why? Well, consider the following script, which maps a network drive:
Set objNetwork = Wscript.CreateObject("WScript.Network")
objNetwork.MapNetworkDrive "G:", "\\atl-fs-01\Sales"
Two lines of code, and it’s pretty easy to zero in on the lines that really matter when it comes to mapping a network drive. After all, there are only two lines of code, and both of them really matter.
But we suppose we wanted to make this a real, live, super-robust script? Well, in that case, we might have to allow people to pass in command-line arguments to specify the drive letter and the remote share. And, of course, we’d have to have code to parse the command-line arguments, and verify that they were formatted correctly (e.g., G: rather than G). We’d have to check the remote share to make sure that it really existed, we’d have to check to make sure drive G wasn’t in use, and, if it was, ask the user if they wanted to disconnect it or to use a different drive letter, we’d have to – well, you get the idea. Suddenly our two-line script might be 40 or 50 lines long. And that’s not an exaggeration.
And so that was the question: should
Besides, even if we wanted to make them more robust (whatever that means), we figured that this would defeat the whole idea of using scripts. Why do people turn to scripting in the first place? Well, usually it’s because the tools supplied with the operating system don’t quite do the trick; people have unique needs that can’t always be met by pre-supplied tools (they want the output formatted differently, they want the output directed to a database, they want to read parameters from a text file rather than supplying them as command-line arguments, etc.). Rather than try to deal with all that, we decided to: 1) Keep the scripts as simple as possible; and, 2) Provide additional information that will enable people to add command-line arguments or reformat the output or do whatever they want to these basic scripts. And so that’s why