Win 2000/XP users: Use the SET statement with it's /P (prompt) switch. This does NOT work for NT4. There is a 'MS-DOS' kludge that will work, but you're probably better off using this WScript approach instead.

A trivial correlary to this is a routine for prompting the user for input (using WHS). Unfortunately, there is no good way to put these two into one script, because of the need to post process the output. (Try it - you'll understand what I mean.)

Getting string input into a running batch file has been a problem from the beginning of DOS, generally solved through the use of a third party utility. One such is PC Magazines general batch augmentation utility, Strings.com (NO LONGER AVAILABLE at ftp://ftp.zdnet.com/pcmag/1992/1222/strings. zip, but maybe a web search will find a copy somewhere). Back in 1994, I developed a technique using features of the FC.EXE utility in very unusual ways to implement a 'pure DOS' input routine (see DOS Input). This original approach is now decidedly dated.

I have updated the approach to be more in keeping with the general look and feel of Window's GUI interface. It is based on the little batch file shown here, a specially constructed shortcut and the Windows 95/98 START utility.

My initial construct for the new Input95.bat was pretty simple. But, I decided it was better to have most of the required setup code built in and to have the name of the variable that receives the input data as a command line option. This means the input routine is significantly more complex, but that the calling routine is greatly simplified.

An important requirement of this approach is that the Input.bat routine be invoked via a shortcut (Input.pif) rather than by calling it directly. The shortcut is constructed with two special features. First, the literal string '%Title%' (without the quotes) must be entered as the first line on the 'Program' tab of the shortcut 'Properties' dialog. Second, a question mark is added to the end of the 'Cmd line'. (See Figure 1.)

---

Figure 1. Construction of the Input Shortcut.

---

Assuming the Input95.bat routine is located in a folder named in the PATH statement, the calling batch procedure simply invokes the new and improved input routine something like this:

set Title=A test of batch file input call input95.bat This will pop-up a dialog box, because of the question mark in the shortcut. The dialog will have the contents of 'Title' as its prompt string and store the result in the default variable 'Input'. Unfortunately, the run time title becomes permanent once Input.pif is run. Also, if the prompt string exceeds 29 characters the name of the environment variable will be displayed instead of its contents. The solution to the title replacement is to run a copy of Input.pif that is deleted after each execution. This is done automatically within Input.bat, but is restricted to a hard coded designation for the storage of the original copy of the PIF file. I can't think of a good solution to the 29 character limit beyond care in constructing the Title string.

The following procedure demonstrates some of the versatility afforded by this approach.

This demonstration procedure requests two sets of user input, something that cannot be done with a shortcut alone. In addition, the first request will not accept an empty string. An error message is displayed and the title of the input dialog is changed for the retry. I believe this approach significantly extends the versatility of a batch procedure under Windows 95.

One other feature of TInput95.bat that is worthy of note is the construct in the last line. The PROMPT/CLS combination insures the DOS session will close, regardless of the method used to invoke TInput95.bat. Normally, batch files started from an Explorer window or from a shortcut that does not have its 'Close window on exit' feature selected will remain open even after the procedure has ended. I suppose this is to allow the user to see the output or error messages before the window is closed. In some cases this may be a useful feature, but most of the time I find the behavior annoying.

The new and improved version still won't work in Windows NT. NT does not support the question mark on the 'Cmd line' to invoke run time user input. I saw a treatise somewhere that reconfigured Win NT to support this feature, but I didn't make a note of the URL, sorry. Maybe a web search will turn it up. Otherwise, you'll have to invest some time in figuring out the Win Script Host (see http://msdn.microsoft.com/scripting/default.htm).