Back near the end of 1994, I stumbled onto a gold mine of new functionality in a very unlikely place - the FC.EXE program ("FC" for file compare). I had found little use for it until my discovery of a way to use it to input data into a running batch file. It was often deleted from the DOS directory when I was confronted with a machine with limited drive space. However, used in ways that the developer probably never envisioned, it can perform a large number of tasks. Contrary to assertions made in the August 1996 issue of DOS World, explainations of two uses, data input and capitalization of a string, were first published in PC Magazine during 1995 (Vol 14, #12, 27 June, p248 and Vol 14, #14, August, pp327-328, respectively). An updated version of the data input approach is described here.

The secret to using FC to input data from the keyboard is to compare two standard system files, CON and NUL (Win NT users see note below). The CON file captures the keystrokes as with the previously documented COPY CON ... approach. The difference is that FC has a switch (/LBn) that controls the length of an internal line buffer. When the line buffer is set to one, the process is terminated at the end of the first line that is different. This happens upon pressing the Enter key when the CON input is compared to NUL. The user does not need to be prompted to press the control-Z key, nor does the ANSI.SYS driver need to be loaded to allow redefinition of the Enter key to provide the control-Z.

The batch file, INPUT.BAT, shown below, provides a full featured input function that works in much the same way as does the INPUT command in QBASIC. The syntax is ...

CALL INPUT PromptFile Arg1 [Arg2 [Arg3 ...]]

The first argument is the name of a file containing a prompt string. A full path name must be provided if the file is not in the current directory. If the file is not found, INPUT substitutes a question mark. After the prompt is displayed, the routine waits for input with the cursor positioned at the end of the prompt string. Each word in the input string, up to the number of arguments provided, is returned in the environment variables named as arguments on the CALL INPUT line.

At least one environment variable name must be supplied or a syntax error will occur. No error checking is done in INPUT.BAT to steamline its operation. It is assumed it will only be used as a call from another procedure and that all error handling is done in the calling routine.

The procedure is supported by another routine, NOLINE.BAT, that prints the contents of a file without a trailing carriage return/line feed. That is, a prompt string is output with the cursor waiting on the same line.

All the standard DOS edit keys can be used while keying in input, so they cannot be made part of the input string. As a consequence, this approach will not return the escape key, the backspace or function keys as data. Likewise, the standard DOS delimiters (comma, semicolon, space, equal sign and tab) act as delimiters in the input string and are all returned as a single space. Redirection characters ("<", ">" and "|") should not be used unless they are surrounded by double quotes, otherwise they will cause errors or erratic behavior.

In use, the routine could be implemented something like this

... ECHO Enter input and output file names: > {PROMPT} CALL INPUT {PROMPT} INFILE OUTFILE DEL {PROMPT} IF [%INFILE%]==[] GOTO FIL_ERR1 IF [%OUTFILE%]==[] GOTO FIL_ERR2 ... The names of the files provided by the user will be returned in the environment variables INFILE and OUTFILE respectively in this example. If no name or only one is provided, the INPUT routine removes the variable(s) from the environment, which permits error handling. (Note that labels have only eight significant characters, though they can be of any length. This means that a label called File_Error_1 is equivalent to File_Err999, so some care must be exercised in naming labels.)

The novel use of the DATE function has nothing to do with the date. Rather, its output, "Enter new date (mm-dd-yy): ", prefixes the output of the FC command. This permits the input data to be processed by the ENTER.BAT file, constructed between the LOOP and END labels. The ENTER batch file is invoked by the CALL to the ENTE}.BAT file. In general, one line from the redirected output of any process can be handled this way. The redirected text must end in a blank line (CR/LF) to terminate the DATE command, or the whole process hangs up until the user presses CTRL-BREAK. Fortunately, the FC command adds two blank lines to its output. Otherwise, a blank line can be appended to a file using an ECHO. (or VER for DOS versions earlier than 5.00) before it is redirected into the DATE function.

Note that the usage of DATE described here works correctly for English versions of DOS. Other languages will probably need to make adjustments to match the exact phrase that is output from the DATE function. In particular, the names of the secondary batch files, ENTER.BAT and ENTE}.BAT, must match the first word in the second line of output and the number of the argument at the end of the ninth line needs to match the word count on that line.

---

A Final Note: Chris Kovach, a Win NT user, has brought to my attention a problem with using this routine in that context. Win NT does not support the use of the standard I/O devices (CON, NUL, etc) as arguments in the FC.EXE utility. Be advised, this makes INPUT.BAT useless in that environment. Sorry, I do not have a fix except to tell you to go to your favorite PC/MS-DOS ftp site or to www.zdnet.com/pcmag and find a copy of PC Magazine's venerable utility, STRINGS.COM.