FreeCOM Pipes on DOS: Temporary Files, Sequential Stages, and Failure Modes

A FreeCOM pipeline looks familiar to users of Unix-like shells: producer | consumer. Its implementation has an important DOS-specific property, however. FreeCOM documents that DOS is not a multitasking environment and simulates a pipe with temporary files. In a three-command pipeline, the first command writes an intermediate file, the second reads it and writes another, and the last consumes the second file. This is not a concurrently running, bounded-memory stream.

That design affects performance, disk capacity, failure recovery, and what “the next command” means. Large output can consume temporary storage; the consumer does not read data while the producer is running; and an interruption can leave work to inspect or clean up. A pipeline is useful for text-oriented DOS utilities, but it must be planned as a sequence of file operations rather than assumed to have operating-system pipe semantics.

What FreeCOM documents

FreeCOM’s feature documentation describes a pipeline such as:

cmd1 | cmd2 | cmd3

as equivalent in broad data flow to cmd1 output becoming cmd2 input, followed by cmd2 output becoming cmd3 input. The implementation uses temporary files in %TEMP%, with names patterned in the documentation as cmd###1.tmp and cmd###2.tmp. The files are removed after they are no longer required: the first after the second command terminates and the next after the final command terminates.

The important property is sequential execution. FreeCOM must complete one command’s output file before launching the next stage that reads it. A slow producer cannot be overlapped with a consumer to smooth throughput. A pipeline therefore pays for disk writes and rereads, and it can run much more slowly than a memory-backed pipe on a multitasking operating system.

Do not generalize this implementation to every DOS shell. FreeCOM is a COMMAND.COM replacement used by FreeDOS, and another command interpreter may have different behavior or syntax. Confirm the shell path and version before using this article as an operational expectation. A FreeCOM prompt can report the shell version using its documented prompt escape, but a production log should record the actual binary or package version as well.

Temporary storage is part of the pipeline contract

The %TEMP% directory must be valid and writable for the commands that use the pipeline. Each intermediate stage needs enough space for its output, even if the final result is small. If DIR emits a large listing, or an inventory command prints thousands of records, FreeCOM must write that material before the consumer can start. A full or read-only destination can break the pipeline before the application sees any input.

Before a maintenance pipeline, inspect the variable and test a harmless file creation in the intended directory. Avoid setting TEMP to removable media that can be swapped, a read-only CD-ROM, or a nearly full disk. If no usable temporary path exists, redirect to a known working volume or use a simpler one-command workflow. Do not assume that a DOS shell has a RAM-backed temporary store simply because an application uses XMS.

Temporary files are implementation artifacts, not durable logs. FreeCOM’s documentation says it removes intermediates when stages finish. A reset, crash, power interruption, or termination in the middle of a stage may prevent normal cleanup; treat leftover files as possible, but verify the installed build rather than assuming a particular name sequence or cleanup policy. Never delete a file merely because its name resembles a pipe temporary. Check its location, time, and the current shell process first.

Pipes are not a live stream or a concurrency primitive

On a multitasking host, a traditional pipe can allow the writer and reader to progress concurrently, with buffering and backpressure. The documented FreeCOM file simulation has different behavior: the writer completes first, and the next command then reads the completed file. There is no live producer-to-consumer handoff and no kernel pipe buffer that throttles a fast producer when the consumer is slow.

This difference matters when measuring elapsed time. A three-stage pipeline may perform two complete temporary-file writes and reads before final output is produced. The exact data volume and filesystem can dominate runtime. If a stage expects interactive input, writes progress messages to a device, or depends on the current directory, test the exact command sequence outside the pipeline first. A DOS utility that treats standard input as a console may not consume a redirected file as expected.

Pipes also do not automatically make a sequence transactional. If stage one succeeds and stage two fails, the temporary file may contain useful intermediate evidence. If stage three fails, the earlier stages may already have completed and their temporary data may be removed during normal cleanup. Capture persistent output explicitly when it matters and test the return-code behavior of the exact FreeCOM version before relying on a pipeline’s final ERRORLEVEL for automation.

Redirection syntax and a safe example

FreeCOM documents the redirection operators <, >, and >> in command lines. A simple read-only example is:

dir c:\freedos\bin | more

The command produces a listing, FreeCOM stores the intermediate output, and MORE displays the resulting text page by page. This is appropriate for inspection, but still requires writable temporary storage. If that assumption is uncertain, run DIR alone or direct output to an explicitly chosen file on a known writable volume.

For a repeatable inventory, separate the durable log from the ephemeral pipe intermediate:

dir c:\freedos\bin > c:\logs\bin-list.txt
type c:\logs\bin-list.txt | more

This example assumes the C:\LOGS directory already exists and has free space. The first redirection overwrites its target, so do not use an existing path unless replacement is intended. The second command still uses FreeCOM’s pipeline implementation for the temporary handoff; bin-list.txt is the durable record. On a different shell, confirm TYPE, redirection, and pipeline syntax separately.

Avoid piping binary data unless both producer and consumer are documented to preserve every byte through DOS standard handles and FreeCOM’s temporary-file route. The feature documentation presents pipes as command stream connections; it does not promise that every text-oriented command is binary-transparent. For exact data transfer, use a utility with a documented binary mode and compare the resulting file with an independent checksum.

Troubleshooting without destroying evidence

If a pipeline fails, record the full command, FreeCOM version, value of TEMP, available disk space, and exact message. Then run each stage separately with explicit input and output files. This distinguishes a producer failure from a temp-directory problem, consumer input behavior, or an unsupported command syntax. Preserve any remaining intermediate file until its role is understood.

If the result is unexpectedly empty, check whether the first command produced output when run alone, whether the target volume is correct, and whether the consumer expects a filename rather than standard input. If the result is truncated, inspect free space and any output limits in the utility. If execution is unexpectedly slow, compare the sizes of intermediate outputs and consider avoiding the pipeline for very large data sets.

Do not use a pipeline as a proof of successful upstream execution unless the shell’s exact status-propagation rule is documented and tested. A downstream command can successfully process an empty file after an upstream failure. In a maintenance batch file, capture and inspect each stage’s status using a tested FreeCOM pattern, or write intermediate files and check them before continuing.

Acceptance checklist

Before relying on a FreeCOM pipeline, confirm that the intended command processor is running, %TEMP% points to a writable location with adequate space, each program supports the redirected stream it receives, and the exact version’s exit behavior is understood. For high-value output, preserve a separate durable file and checksum it. Treat pipeline intermediates as ephemeral files, not as the only copy of an audit record.

FreeCOM’s file-backed pipeline makes familiar syntax available in a single-tasking DOS environment, but the temporary-file boundary is visible operationally. Account for sequential execution, storage consumption, cleanup, and command-specific stream behavior, and the pipeline can remain useful without being mistaken for a modern streaming primitive.

Related:

Sources: