Here is the batch file:

start /w wscript.exe userin.vbs
call ~userin.bat
del ~userin.bat
echo You entered %USERIN%

Now the script file I call "userin.vbs"

strUserIn = InputBox("Enter Data")
Set fs = CreateObject("Scripting.FileSystemObject")
strFileName = fs.BuildPath(Wscript.ScriptFullName & "\..", "~userin.bat")
strFileName = fs.GetAbsolutePathName(strFileName)
Set ts = fs.OpenTextFile(strFileName, 2, True)
ts.WriteLine "set userin=" & strUserIn
ts.Close

While the "two separate files" version above will run on any machine that has scripting, trying to write a batch file that will create the script "on the fly" has to be handled differently under NT and 9x. That's because the ampersand has special meaning under NT. When the batch file tries to "echo" a "&" character, NT requires that a caret "^" precede it. If you want to write a batch file that works under NT and 9x, you need to test for how ampersands are handled:

@echo off
:: First test to see if we are on NT or similar OS
:: The ony difference is how they handle the ampersand
 > ~userin.vbs echo 1234&rem
type ~userin.vbs | find "rem" > nul
if errorlevel 1 goto WINNT
goto WIN9X

:WIN9X
 > ~userin.vbs echo strUserIn = InputBox("Enter Data")
>> ~userin.vbs echo Set fs = CreateObject("Scripting.FileSystemObject")
>> ~userin.vbs echo strFileName = fs.BuildPath(Wscript.ScriptFullName & "\..", "~userin.bat")
>> ~userin.vbs echo strFileName = fs.GetAbsolutePathName(strFileName)
>> ~userin.vbs echo Set ts = fs.OpenTextFile(strFileName, 2, True)
>> ~userin.vbs echo ts.WriteLine "set userin=" & strUserIn
>> ~userin.vbs echo ts.Close
goto RUN

:WINNT
 > ~userin.vbs echo strUserIn = InputBox("Enter Data")
>> ~userin.vbs echo Set fs = CreateObject("Scripting.FileSystemObject")
>> ~userin.vbs echo strFileName = fs.BuildPath(Wscript.ScriptFullName ^& "\..", "~userin.bat")
>> ~userin.vbs echo strFileName = fs.GetAbsolutePathName(strFileName)
>> ~userin.vbs echo Set ts = fs.OpenTextFile(strFileName, 2, True)
>> ~userin.vbs echo ts.WriteLine "set userin=" ^& strUserIn
>> ~userin.vbs echo ts.Close
goto RUN

:RUN
:: Now run the created script
start /w wscript.exe ~userin.vbs
del ~userin.vbs

:: Now call the created batch file
call ~userin.bat
del ~userin.bat

:: Now display the data!
echo You entered %USERIN%
pause
cls

If you find yourself needing to enter passwords and you want to mask the passwords so they aren't visible, you can use a combination of scripting and HTML or (if you have IE5 or newer) you can use scripted HTA files.
 
There is another scripting approach that stays in the DOS box (it doesn't use a graphical window input method). It uses the "Wscript.StdIn" object to get user input. The only bad part is that Wscript.StdIn isn't part of the scripting client that shipped with Win98 or with NTSP4. However, since everybody keeps their computers updated these days(except grandma on dialup), everybody should have a fairly recent version of scripting.

Here's a batch file that lets the user enter a number. It works by having the script exit with an error code that matches the number:

echo wscript.quit wscript.stdin.readline> ~userin.vbs
echo Please enter a number
cscript.exe //NoLogo //B ~userin.vbs
echo You entered %errorlevel%
del ~userin.vbs

Actually, referring to the %errorlevel% variable like I show only works on NT and newer.  Code that works everywhere would test for every separate errorlevel using  the typical "if errorlevel 9 goto label9" syntax. 

If we try to extend the above five line example to allow any text (not just numbers) to be input, it gets a bit more complex. In fact, it ends up looking exactly like the first example(s) except that the line:

 > ~userin.vbs echo strUserIn = InputBox("Enter Data")

gets replaced with this:

 > ~userin.vbs echo strUserIn = wscript.stdin.readline

Right now you're thinking (maybe) that if  "InputBox" and "wscript.stdin.readline" can be swapped so easily, can we use the InputBox in the short numbers-only batch file? Sure!

echo wscript.quit InputBox("Please enter a number")> ~userin.vbs
cscript.exe //NoLogo //B ~userin.vbs
echo You entered %errorlevel%
del ~userin.vbs

QBASIC.  If you aren't using Win9x and want to stick with a non-gui interface, this is it. QBASIC isn't installed on most systems, so you may have to force a download or put the qbasic program files in the same location as your batch file (real easy if it's a network drive!). Again (just like above), I'll teach batch, but not QBASIC. So I'll show a batch file creating a qbasic script, but I won't explain the script. I can only do so much!

The batch file here will generate a separate qbasic script "~usrin.bas", then run that script with qbasic. All the script does is create a separate batch file "~usrin.bat" that puts the user input into the environment.

@echo off
echo OPEN "~usrin.bat" FOR OUTPUT AS #1> ~usrin.bas
echo INPUT "Enter your name ", sUsrin$>> ~usrin.bas
echo PRINT #1, "set usrin="; sUsrin$>> ~usrin.bas
echo CLOSE #1>> ~usrin.bas
echo SYSTEM>> ~usrin.bas
qbasic /run ~usrin.bas
call ~usrin.bat
del ~usrin.bat
del ~usrin.bas
echo Your name is %usrin%
pause
cls

I've had scattered reports that the above code doesn't run on code page 437 (US) but works on code page 850 (Multilingual). But I use code page 437, and the code works identically for me under Win95 and NT4. Just FYI.  Eric Rose, someone who knows NT better than I do, found that if you have problems with QBASIC using expanded memory in ways NT finds unacceptable, you can make everybody happy by adding this line

set RTVMEXP=0

to the beginning of the batch file (actually the second line, just after the "@echo off" line).

In the above example, I create the QBASIC  code as it is needed. You can speed things up considerably by creating the code ahead of time and having it kept as a permanent item. Here is  the code rewritten as two separate files.  First, the batch file:

@echo off
qbasic /run userin.bas
call ~userin.bat
del ~userin.bat
echo Your name is %userin%

Now the QBASIC file I call "userin.bas"

OPEN "~userin.bat" FOR OUTPUT AS #1
INPUT "Enter your name ", sUsrin$
PRINT #1, "set userin="; sUsrin$
CLOSE #1
SYSTEM

If you find yourself needing to enter passwords and you want those passwords masked, you can use QBASIC to mask the passwords with asterisks.

@echo off
choice /n /c:123 Please choose 1 for Doom, 2 for Duke, or 3 for Keen:
if errorlevel 3 echo Keen
if not errorlevel 3 if errorlevel 2 echo Duke
if not errorlevel 2 if errorlevel 1 echo Doom
In this case, all I did was echo the word corresponding to the number you select. You'd probably want to run a more useful command or launch another batch file. Read the help on IF to learn more about ERRORLEVEL. Because ERRORLEVEL always tests for a "greater than or equal to" condition, complicated testing for exact error levels like shown above (Or using lots of GOTOs and labels) is usually necessary.

If you want to use CHOICE in an somewhat more complicated way, you could have it check for every possible keypress, then accumulate each key in an environment value. This way you could build up an entire word or number a character at a time. The following example shows a limited password-entry example:

@echo off
set userin=
echo Please enter a sequence of letters a, b, or c. Enter q to quit.
:rerun
choice /n /c:abcq > nul
for %%x in (1,2,3,4) do if errorlevel %%x goto add%%x
:add1
set userin=%userin%a
goto rerun
:add2
set userin=%userin%b
goto rerun
:add3
set userin=%userin%c
goto rerun
:add4
echo Your sequence was %userin%

Now, the NUL device has nothing in it, so when FC compares NUL to CON, the difference will always be exactly what the user keys into CON. Duh. But FC's /lb option allows us to specify how many different lines will be accepted. With /lb1 specified, FC will quit reading con after the first different line (which will be the first line). All the user has to do is hit "Enter" to define the end of the line.

We also use FC's /n (line numbering) option for two reasons: First, FC puts out quite a few lines. Having it number the lines makes it easy to FIND the line we want. Second, we'll be putting the output of FC into the input of DATE (wonder why?). By numbering the line, we can allow for the otherwise embarrassing problem of having the user enter as a first word something that might be interpreted as a date. The first word will be "1:", which is not a date.

Let me illustrate FC. First, with no options. Notice how I had to enter a Ctrl-z to terminate things. FC's output starts with the line containing "****** CON". My input is the line "this is a test".

C:\Temp>fc con nul
Comparing files CON and nul
this is a test
^Z
****** CON
this is a test
****** nul
******

Next, I'll add in the /LB1 option.

C:\Temp>fc /lb1 con nul
Comparing files CON and nul
this is a test
Resync failed.  Files are too different
****** CON
this is a test
****** nul
******

C:\Temp>fc /lb1 /n con nul
Comparing files CON and nul
this is a test
Resync failed.  Files are too different
****** CON
     1:  this is a test
****** nul
******



C:\Temp>

C:\Temp>fc con nul /lb1 /n | date
this is a test
Current date is Wed 05-14-1997
Enter new date (mm-dd-yy): Comparing files CON and nul

Invalid date
Enter new date (mm-dd-yy): Resync failed.  Files are too different

Invalid date
Enter new date (mm-dd-yy): ****** CON

Invalid date
Enter new date (mm-dd-yy):      1:  this is a test

Invalid date
Enter new date (mm-dd-yy): ****** nul

Invalid date
Enter new date (mm-dd-yy): ******

Invalid date
Enter new date (mm-dd-yy):

C:\Temp>

Enter new date (mm-dd-yy):      1:  this is a test

Now it's time to show the completed example. This only asks for one word:

echo Enter your first name
echo set name=%%5>enter.bat
fc con nul /lb1 /n | date | find " 1: " > temp.bat
call temp.bat
del temp.bat>nul
del enter.bat>nul
echo Your name is %name%.

In this example, because my ENTER.BAT was very simple (set name =%5), I created it by using echo in the second line of the example. Your ENTER.BAT can contain anything you want. If you have a need to process an unknown number of words, just keep using SHIFT to get the next argument. Test each argument after you get it to see if it is blank. If it is, you have no more arguments. Here is an example ENTER.BAT illustrating this:

set name=
:loop
set name=%name% %5
shift
if not "%5"=="" goto loop

Generally, if you write a batch file that expects multiple arguments to be entered by the user on a single line, you're asking for trouble. Think about how much easier it is to get user input and verify it's validity if you do it one step at a time. Nobody enjoys retyping an entire line because one word got messed up the first time. But you'll assume mistakes will never happen.and write multiple-argument code anyway. You can reference %5, %6, %7 (for example) as your first, second, and third arguments. You can go all the way to %9 for your fifth argument. Usually it's enough. If you expect more than five arguments, you'll need to use shift.

fc /lb1 con nul | find /v "*****" | find /v "Resync failed." | find /v "Comparing files" > temp.txt
copy fragment.txt + temp.txt temp.bat

set name=Foo, King of Bar

Anyway, if you really want to do it, the code to redefine the Enter key to "Ctrl-z Enter" is [13;26;13p and the code to return Enter to normal is [13;13p. Both these codes must be preceeded by the "escape" character (which doesn't print, so isn't displayed on this web page). An escape character can be generated in Windows Write by holding down the Alt key while typing in 027 using the numeric keypad. You can generate an escape in DOS EDIT by hitting Ctrl-p, then the Esc key. The classic use is to append the con to a line fragment, creating a batch file. Suppose you had a pre-existing line fragment called userfrag.txt containing set userin=

@echo off
echo Enter your name: [13;26;13p
copy userfrag.txt + con temp.bat
echo [13;13p
call temp.bat
del temp.bat
echo Your name is %userin%