How Come All the Script Center Scripts Are So Simple?

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. Bob Wells once did a study of some scripts that shipped with the Windows 2000 Resource Kit. What he invariably found was that in a script that might be 500 lines long, only 40 or so of those lines would really do something. The rest of the lines took care of command-line argument parsing, error-message reporting, and other ancillary tasks. That’s fine for production-level scripts that are intended to be used as-is, not so fine for teaching scripts designed to show you the basic concepts (with the expectation that you will add all the ancillary stuff if you need it).

And so that was the question: should Script Center scripts be educational, or should they be full-fledged production scripts? In the end, those of us on the educational end of things prevailed, primarily because we saw our mission as being as much scripting evangelists as scripting educators; after all, if no one was doing scripting, well, then there wasn’t a whole lot of need for a Scripting Guide. We wanted to get people interested in and excited about scripting, and we figured that showing them how a bunch of simple little 10-line scripts could carry out important tasks would be more effectively than implying that they needed a bunch of big, complicated 1,000-line scripts in order to carry out the same task.

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 Script Center scripts are so simple. (Well, that and the fact that the guys who write the Script Center scripts are pretty simple, too. But that’s another story.)

Comments

• Anonymous
  February 11, 2004
  The comment has been removed
• Anonymous
  February 13, 2004
  The comment has been removed
• Anonymous
  February 16, 2004
  Off on the argument parsing subtopic... :)
  
  I thought that the WScript.Arguments collections were pretty ugly when I first looked at them. After seeing getopt() a few months later, and returning to argument parsing about a dozen times on my own, I realized that it was the "least ugly". And that's not even considering the automated help text support. ;)
  
  
• Anonymous
  July 15, 2004
  Count up all the sentences that contain an error