Hey, Scripting Guy! How Can I Prompt a User for Information and Then Pass That Information to a Command-Line Tool?
Hey, Scripting Guy! How can I prompt a user for information and then pass that information to a command-line tool?
Hey, SD. efh;r9d/fjwf
Sorry; let’s try that again. j ewewrj 2gr CX # 2kkkkw
Sorry; the Scripting Guy who writes this column is having a little difficulty moving his arms today. Last night the Scripting Son thought it would be “fun” to go to the gym and swim laps for 40 minutes instead of going to the gym and riding the exercise bike for 40 minutes.
Did we ever mention how dumb the Scripting Son is?
Note. OK, good point: if the Scripting Son is dumb for suggesting that the two swim laps for 40 minutes, what does that make the Scripting Dad for agreeing to that suggestion? Don’t bother; we all know the answer to that question. Making things even worse is the fact that the Scripting Dad knows better. Back in his high school days, one of his PE teachers offered to give anyone an A for the quarter if they could complete a one-mile swim in a specified amount of time. The Scripting Guy who writes this column was able to complete the swim and earn his A. Several days later, when he finally managed to crawl out of the pool, he vowed never to do anything that dumb ever again.
On the bright side, though, suppose the Scripting Dad finds himself on a boat that’s a mile or so off shore and that boat suddenly sinks. After last night, the Scripting Dad knows that he’ll be able to swim all the way back to land, no problem.
Provided, of course, that the water has walls every 50 yards or so that he can rest on.
Of course, the question on everyone’s mind right now is this: will a little thing like not being able to move his arms keep the Scripting Guy who writes this column from actually writing this column? Given his druthers, yes it would. Needless to say, however, the Scripting Guy who writes this column never seems to get his druthers:
Set objShell = CreateObject(“Wscript.Shell”)
strName = InputBox(“Please enter the user name:”)
If strName = “” Then Wscript.Quit
strCommand = “%comspec% /k dsquery user -name ” & Chr(34) & strName & chr(34)strCommand = strCommand & ” | dsget user -tel”
According to your email, SD, you noted that what you really need to do is prompt a user to enter a name, then use the command-line tools Dsquery and Dsget to search Active Directory, locate the user with that name, and then display his or her telephone number. Just to keep everyone else in the loop, here’s the sample command SD sent, with the variable x representing the user name:
dsquery user –name x | dsget user –tel
The script we just showed you? That script will run this very command, substituting the name typed in by the user for the variable x.
No, we don’t have water on the brain. Well, not much anyway. Listen, maybe it will help if we explain how the script works. As you can see, we begin by creating an instance of the Wscript.Shell object; we’ll use that object when it comes time to call our command-line tools. We then use this line of code to pop up an InputBox, solicit a user name, and then store that name in a variable named strName:
strName = InputBox(“Please enter the user name:”)
Our next step is optional, but seemed like a good idea. If you type a name into an InputBox and then click OK (or press ENTER) that name will get stored (in this example) in the variable strName. But what happens if you click the Cancel button instead? In that case, an empty string value (“”) gets stored in strName. On top of that, if you click Cancel that probably means you want to cancel the script. (Yes, we Scripting Guys are pretty darn smart, aren’t we?) Therefore, we inserted this block of code to determine whether or not strName contains an empty string. If it does, we call the Quit method and terminate the script:
If strName = “” Then Wscript.QuitEnd If
Hey, that’s why they pay us the big bucks.
We’re now ready to compose our command-line string (and yes, we usually find it easiest to compose the command-line string, store it in a variable, and only then run the command). This isn’t particularly difficult, but there are a couple of things to watch out for:
Just running the two command-line tools isn’t good enough: the tools will run, but the output will scroll past too quickly to be read. Instead, we need to open a new command window, run the tools, then make sure that the command window stays open when the tools are finished. In our example, that’s what %comspec% /k does (%comspec% opens the command window and the /k keeps the window open).
We have to include the double quote marks in the command. Admittedly, embedding double quotes in a string variable, as we’re about to do, can be a little tricky. But we’ll show you a pretty straightforward way to take care of that.
In order to keep things simple we opted to use two steps in order put our command-line string together. Here’s step 1:
strCommand = “%comspec% /k dsquery user -name ” & Chr(34) & strName & chr(34)
What are we doing here? First we’re opening a new window and ensuring that the window stays open after Dsquery and Dsget finish running; again, that’s what the %comspec% /k is for. We then issue the basic Dsquery command: dsquery user –name. That brings us to the tricky part: specifying the user name, making sure that name is enclosed in double quote marks.
You know, now that we look at the script, it turns out that this wasn’t that tricky after all, was it? Notice that when we included the Dsquery command we put a blank space after the –name parameter; that’s gives us a ready-made spot for entering the user name. That’s something we do using this reasonably-simple syntax: Chr(34) & strName & Chr(34).
What’s all that mean? Well, for starters, the Chr function takes an ASCII value and substitutes the actual character corresponding to that value. As it turns out, the double quote mark has an ASCII value of 34; thus Chr(34) is going to insert a double quote mark for us.
After that we insert the variable strName and a second double quote mark. Assuming you typed in Ken Myer as the user name, the variable strCommand will now be equal to this:
%comspec% /k dsquery user –name “Ken Myer”
Pretty good, huh?
We then use this line of code to add in the second half of our command:
strCommand = strCommand & ” | dsget user -tel”
All we’re doing here is setting the value of strCommand to the current value of strCommand plus this: | dsget user –tel. In turn, that’s going to make strCommand equal to this:
%comspec% /k dsquery user –name “Ken Myer” | dsget user -tel
Which, coincidentally enough, is the very command we need in order to get Dsquery and Dsget to retrieve Ken Myer’s phone number.
In fact, all that’s left now is to call the Run method:
We should point out that this script is simply going to call Dsquery and Dsget and then display Ken Myer’s phone number in the command window. Is it possible to grab that phone number and then use it elsewhere in your script? As a matter of fact it is, but that requires you to do a little bit more coding (and to use the Exec method rather than the Run method). For more information, see the Tales from the Script column “Running Programs From WSH Scripts,” which, for you trivia buffs, happens to be the very first column published in the Script Center.
And yes, it probably is worth a lot of money. Feel free to make us an offer.
As for the Scripting Guy who writes this column, at this point all he can say is dsfhg3e^t r4.
And this time, he means it.