There are two special rules that apply to files:

Either path information or wildcards are allowed in filenames of the first type.  But not both.  Files of the first type are the only ones that allow wildcards.

File names of the fifth type (.com/.exe/.bat) *can't* have path information (i.e. drive, and/or folder names).

All the others can.

Note that FileStat will also check to see whether DOS environmental variable names have been assigned: use a prefix of '%' on the variable name (but don't use one on the end.)

FileStat also reads file names from the standard input.

If you don't want it to read file names from the standard input, just run it like this:

FileStat (other parms) < NUL

FileStat is extremely useful for a wide variety of purposes.

First, if you're very paranoid (as I am) about DOS batch processes that get run remotely, then you should probably put FileStat in every directory (AKA folder) in which a DOS batch file executes.

Then you can start every DOS batch file off with something like this:

If Not Exist FileStat.Exe Echo FileStat.Exe not found, tell Rog!!
If Not Exist FileStat.Exe Pause
If Not Exist FileStat.Exe Goto ABORT_RUN

Why do this?

Because FileStat is your foundation for ensuring that all the files will exist in the batch job that's about to run.  If FileStat itself doesn't exist, then the user will see all sorts of "bad command or file name" messages . . . but you'll have no way of knowing what the problem is (unless you can actually sit down at their computer and check, which is often not an option.)

Now if you believe in "paranoid programming" as much as I do (and/or in "Muphy's Law," which is that: if something can go wrong, then it will), then you should probably use FileStat to validate the existence of every executable that you're going to need:

FileStat ADB.Exe GAwk.Exe RPSort.Com ErrMsg.Exe FileMux.Exe < NUL
>>ADBLOG.%ADBPROJ%
If ErrorLevel 1 Echo *ERROR* Some executables not found, tell Rog!!
If ErrorLevel 1 Pause
If ErrorLevel 1 Goto ABORT_RUN

(I've taken the first line and broken it up into two physical lines, for ease of display.  That has to be one line in your DOS batch file.)

Note that in the above execution of FileStat, I wrote the results to ADB's log file.  If that's going to get zipped up (at label ABORT_RUN), then I'll have all the information I need to do remote debugging.

Generally speaking, you don't need to check for the existence of ADB's files, since ADB will automatically do this for you and write the results into the log.

But if you're running other programs (such as those you've written in some other compiled or interpreted language), then FileStat can save you from having to verify that files exist, and it can make sure that the proper error messages go right into ADB's log file.  Once again, remote debugging is simplified.

FileStat's also handy for temporary files.  Suppose you want to make sure that the files Temp*.Dat are erased before a run:

FileStat !Temp*.Dat < NUL >> ADBLOG.%ADBPROJ%
If ErrorLevel 1 ErrMsg Filestat couldn't erase temporary files!
If ErrorLevel 1 Goto ABORT_JOB

The reason why you'd probably prefer to ensure that temporary files are all erased before the job begins is that there are many situations in which the windows versions of DOS will not allow files to be overwritten (or they may insist on prompting the user).

Worse, the file may be claimed by another process.  If so, all the user will see is "access denied".  That won't give them much of clue as to what's wrong.

Nor will you have the slightest notion either when they call you . . . and they say what all users tend to say, no matter what the problem is, or how many very specific error messages they may have seen.

(I'm talking about those immortal words that describe every computer error in the history of the human race with 100% accuracy, precision, and completeness: "Didn't work."  No technical person or programmer worth his or her salt needs any more information to get to the bottom of any problem encountered by a user, client, or customer.)

You might be wondering why the third type of parameter (file names that begin with a slash) is provided.  These files must exist and be of length 0.

I added this option especially for ADB.  In a typical case in which you're using (say) an invoice file as the "transaction" file for ADB and a customer file as the "master" file, you'd probably expect that every invoice has a valid customer number.

But what if there are some that don't.  Simple.  You create a T-M output file for ADB.  If any invoices are in this file, they'll be unmatched invoices.  That means they have customer numbers that don't exist in the customer file (presuming that you're matching on the customer number).

At the end of the ADB run, you use FileStat to verify that this file of unmatched invoices has length 0.

So FileStat is your "Murphy's Law Detector" when it comes to files that can't be executed, erased, written to, or which (erroneously) contain data.

As the term "Dectector" suggests . . . FileStat can't stop Murphy's Law from wreaking havoc.  But it can certainly make it a lot easier and quicker to clean up the mess.

What about the optional first paramter.  You can code "-Q" (quiet) if you want FileStat to do its work silently (i.e. not to write anything to standard output).  If you code "-P" (pause), FileStat will ask the user to hit the space bar to continue, whenever it encounters errors.

The optional first argument of "-T" (trace) is for those special situations in which Windows gives you "abort, retry, fail" errors, and there's no way of determining which paramter (i.e. file) is causing the problem.

Finally, you may wonder why FileStat reads its parameters from the standard input as well as the command line.  The reason is that the DOS command line is limited to 128 characters, and if you have a lot of files to check, it may be much more convenient to use DOS Echo commands to build a file that's a list of file names (or more precisely: each line in the file is one of the standard command-line arguments, other than the three special and optional "first" parms.)

I have to admit that it's slightly irritating to always have to code "< NUL" whenever I want to use FileStat with nothing other than command-line paramters, but the extra flexibility of being able to read the options from a file has come in handy for some larger jobs.

You can use FileStat's ability to read file names from the standard input in order to document the purpose of a file, since FileStat doesn't understand Windows 95 file names, and will stop reading a file name when it sees a space.  So you can just skip a space (or a tab) and start writing comments.  The only thing is that you do need to put at least one file name (or one of the three special parms described above) on the command line.  You can also just use FileStat.Exe as a "dummy" parm if you wish:

@Echo @FileIn1.Dat This is my first input file   >FileList.Dat
@Echo @FileIn2.Dat This is my second input file >>FileList.Dat
@FileStat FileStat.Exe &llt;FileList.Dat

WARNING:
if you exceed the 128-character limit on the DOS command line, DOS will truncate the line without issuing an error message.  That's why FileStat lets you put file names in via the standard input.

WARNING:
The "-p" parm in order to pause on errors is incompatible with redirecting the standard input!  FileStat doesn't check for this condition, although the on-line help does warn you about this.  If there is an error, the DOS command line will simply "freeze" and you'll have to force windows to close the DOS prompt.

FileStat's one of the most effective ADB utilities: it's worth spending some time to learn how to use it.