FreeCOM IF EXIST: File, Directory, and Device Probes in Batch Files
Build predictable FreeDOS batch guards with IF EXIST, distinguish path checks from device-name tricks, and test wildcard and expansion edge cases.
IF EXIST is a small command with an important contract: it decides whether to run another command based on a path test performed by the command interpreter. In a FreeDOS batch file, this is often the guard before copying a configuration file, loading an optional driver, or entering a tool directory. It is not a generic test of whether a device works, whether a file is readable, or whether an earlier command succeeded. Those questions require different evidence.
FreeCOM’s documented form is IF [NOT] EXIST file command. IF is internal to COMMAND.COM, so the executable’s version and current shell context matter. The FreeDOS help explicitly says wildcards are supported and that local filesystems can also recognize character devices in this test. That last feature enables a historical directory probe using NUL, but it is easy to misread as proof of an ordinary file named NUL.
Start with an exact file guard
For a file whose absence should skip an optional step, use a fully qualified path and a simple branch:
@ECHO OFF
IF NOT EXIST C:\TOOLS\APP.CFG GOTO NO_CONFIG
ECHO Configuration file is present.
GOTO DONE
:NO_CONFIG
ECHO Optional configuration was not found.
:DONE
This checks for a matching directory entry at the moment FreeCOM evaluates the condition. It does not open the file, parse it, validate its contents, or confirm the following program can use it. A permission error, damaged filesystem, changed media, or race between check and use can still make the operation fail. Treat the guard as control flow, then inspect the result of the operation itself. Where the action is destructive, a successful IF EXIST is not enough authorization to overwrite data.
Avoid making the test depend on whichever drive and directory happen to be current. DOS maintains a current directory per drive; C:APP.CFG is not the same name as C:\APP.CFG. A batch file launched from another working directory can silently test the wrong place if it uses a relative path. The full C:\TOOLS\APP.CFG form makes the intended target visible in review. If the drive letter is supplied by configuration, echo the resolved path during a disposable test before relying on it.
Probe a directory deliberately
The FreeDOS IF help includes this idiom:
IF EXIST C:\FREEDOS\NUL GOTO HAVE_DIR
NUL is a DOS character device name. On a local filesystem, the device is virtually present in a directory that exists, so the test can be used as a directory-existence probe. It is not looking for an actual zero-byte file. The help also limits its explanation to local filesystems; a redirector, mapped network drive, emulator, or unusual device namespace may behave differently. Test the exact environment before making a boot script depend on the trick.
For a critical workflow, keep a separate check for the expected contents. A directory can exist while an executable or data file inside it is absent. For example:
IF NOT EXIST C:\TOOLS\NUL GOTO NO_TOOLS_DIR
IF NOT EXIST C:\TOOLS\APP.EXE GOTO NO_APP
This distinguishes a missing directory from a missing application. It still does not prove the executable is valid or runs successfully. Execute it only after the checks and handle its returned status separately.
Understand wildcard matches
FreeCOM documents wildcard support in the EXIST condition. IF EXIST C:\DATA\*.TXT asks whether at least one name matches; it does not enumerate all matching files or guarantee that the one the next command uses is the same one. A wildcard is useful for deciding whether a batch needs to enter a processing branch, but it is unsuitable as a unique identity check.
Filename exposure also depends on the installed environment: FreeDOS provides long filenames only when a driver such as DOSLFN is loaded, and without one, names are limited to the 8.3 form. Do not assume a wildcard expression tested in one environment matches identically in another where long-filename support differs; test both configurations if the batch may run on both. Use an exact known filename for an important prerequisite. If a batch must process every match, use a controlled loop or program that enumerates entries and handles each result; the boolean IF EXIST result alone does not describe the set.
Test a wildcard guard with an empty directory, exactly one match, several matches, and a misleading near-match. Record the shell version and whether long-filename support is loaded. This catches an easy maintenance error: a later operator adds a second file matching the mask, while the script still treats the existence test as if it identified the original one.
Keep EXIST separate from return codes and string tests
FreeCOM supports other IF conditions, but they answer different questions. IF ERRORLEVEL n tests whether the current exit status is at least n, not whether a file exists. The documented IF string==word forms compare expanded text, not the filesystem. Branching on a tool’s exit code after running it is the correct way to learn whether the tool reported success; testing for its output file before running it is a different, earlier check.
Variable and argument expansion is another source of surprises. In batch files, %1 and environment variables are expanded before the condition is evaluated. The FreeDOS IF help’s examples show %1 expanding to arbitrary text: in the unquoted form it may contain embedded whitespace but not an embedded ==, and metacharacters inside it are evaluated; the quoted form IF "%1"=="first name" compares the whole expanded string, including spaces. If a variable intended as a path is empty, a test can become malformed or target a different token. Print the expanded path in a test profile, validate any externally supplied value, and avoid concatenating untrusted batch arguments into an operation that writes files. Quoting in DOS shells is not identical to a modern POSIX shell; the FreeDOS IF help documents separate quoted and unquoted string-comparison forms, so do not apply shell-quoting assumptions from Linux scripts mechanically.
A simple structure keeps the evidence honest: check for the exact prerequisite, run the operation, immediately branch on its documented error level if it has one, and verify the resulting artifact. Do not insert a diagnostic command between the operation and the error-level check without knowing whether it changes the status. The FreeDOS help’s separate ERRORLEVEL documentation is useful here because IF ERRORLEVEL n uses threshold semantics; test higher values before lower values when different failure codes need different branches.
Diagnose a surprising false or true result
When an IF EXIST branch misfires, capture the exact expanded path, current drive, current directory for that drive, FreeCOM version, filesystem type, and whether the location is local or redirected. Check the path manually using DIR and test an exact name before a wildcard. For a directory probe, compare the NUL idiom with a known file inside that directory; the two tests have different meanings.
Run the diagnosis on a copy or disposable environment when the surrounding batch performs writes. Temporarily replace the action with ECHO so the branch can be observed safely. Do not “fix” an unexpected result by adding NOT until the target path and expansion have been verified. A wrong drive letter, omitted backslash, or device-name assumption can invert the observed behavior without any defect in FreeCOM.
IF EXIST is reliable when its question is kept narrow: does a specified local path or wildcard match at this moment under this shell’s rules? Use exact paths and explicit follow-up checks for anything stronger. That makes startup and maintenance scripts easier to review, test, and recover when media or environment changes.
Related:
- How to Use FreeCOM Batch Features Beyond a Linear Startup Script
- DOS Path Resolution: Current Drives, Per-Drive Directories, and Relative Names
Sources: