FreeDOS MORE: Paging Files and Command Output Without Losing the Evidence
Use FreeDOS MORE to inspect long text and piped command output, while preserving the distinction between display paging and durable logs.
FreeDOS MORE is a console pager: it presents text a screen at a time so an operator can read a long file or a command report without watching earlier lines scroll away. It accepts a file, multiple file names, redirected input, and output from a command through a pipe. Its tab-width option can make text easier to inspect, while the interactive keys move between pages, files, and the end of the session.
MORE should be treated as a viewing aid, not as a log collector, parser, or archival format. A page boundary is a display decision, not a record boundary. Quitting the pager does not prove the producer finished successfully, and seeing the last visible line does not prove that the source was complete. For diagnosis, preserve a durable copy of the command output separately and then page through that copy.
Select one input path deliberately
The FreeDOS help documents several useful forms:
MORE C:\FREEDOS\DOC\README.TXT
MORE /T4 C:\FDCONFIG.SYS
TYPE C:\TEST\REPORT.TXT | MORE
MORE < C:\TEST\REPORT.TXT
DIR C:\FREEDOS\BIN\*.EXE | MOREThe first form displays a named file. The tab option /Tn accepts a value from 1 through 9 and controls how tabs are expanded for display. The pipe form receives another command’s output. The input-redirection form supplies a file as standard input. Use one of these forms for each step in a runbook and avoid mixing a broad wildcard with an important diagnosis until you know exactly which files it expands to.
The program’s interactive keys are scoped to file viewing in the FreeDOS reference: Space moves to the next page, N advances to the next file, and Q exits. Do not assume that every key is available or meaningful in exactly the same way for a pipe, redirected input, or a build from another distribution. Check MORE /? on the target and test its behavior with a small file before relying on a keystroke in a procedure.
When several files are passed, the user interface may show transitions between them; retain the filenames in the command line or notes so a copied excerpt can be traced back. Wildcards are documented, but their expansion is determined by the DOS environment and the installed implementation. If the order matters, enumerate the files first and pass explicit names. The pager does not give each page a durable identifier that survives file changes.
Page command output without changing the command
Piping a report through MORE helps when a DOS command emits more than the display can retain:
FDISK /DUMP | MORE
TREE C:\PROJECT /F | MOREUse commands and option spellings verified on the target. The FreeDOS help explicitly gives FDISK /DUMP | MORE and TREE examples; another FDISK build may not expose the same dump switch. Treat the pipe as a presentation path: it allows the producer’s text to be read interactively, but it is not equivalent to capturing a transcript to a file.
For an incident record, capture the command and its result before paging:
DIR C:\FREEDOS\BIN\*.EXE > C:\TEST\BIN-LIST.TXT
MORE C:\TEST\BIN-LIST.TXTThis example creates a new report file, so verify that the chosen directory is writable and the filename is not a valuable existing file. If you must preserve an earlier report, choose a fresh name rather than truncating it with >. After capture, verify that the file exists and is nonempty, record the command and environment, then inspect it with MORE. If the command could return a meaningful ERRORLEVEL, capture or check it immediately after the producer; starting another program may overwrite the shell’s last-result state. Do not claim that a piped command preserved an exit code unless you have tested the actual FreeCOM implementation.
MORE’s page stops are not timestamps or checkpoints. A producer may have completed before the first keypress, or may still be feeding data while a pipe is being read. The pager only controls how text is displayed. If the command’s progress or completion matters, use the command’s own status and a saved output file.
Understand line width, tabs, and character bytes
The /Tn option is a rendering choice, not a transformation of the source file. If a document uses tabs for columns, different tab widths can change alignment while leaving the bytes untouched. Preserve the original file if whitespace matters. Do not overwrite a configuration file with copied screen text from the pager; terminal wrapping, page prompts, and display code page can all make that transcription differ from the underlying bytes.
DOS displays bytes according to a console and code-page configuration. MORE’s support for NLS and long filenames does not turn its input into Unicode. Accented characters or box-drawing glyphs can look incorrect because the source encoding, console code page, font, or output device differs. Before diagnosing corrupted text, compare a known byte sequence using an appropriate inspection tool and separate the saved file’s bytes from the glyphs rendered on screen.
Wide lines also need deliberate handling. A terminal can wrap or truncate visually depending on its width and on the pager’s implementation. A line split across physical display rows is still one logical source line. When recording a critical path, number, error string, or command option, copy it from the saved source rather than trying to infer where a wrapped line continued.
Keep interactive display separate from batch processing
MORE is appropriate for a human at a console. It is usually inappropriate in an unattended batch job because the program may wait for a key, block a pipe, or consume input that a later command expected. If a job is scheduled or run without an operator, write to a log file and ensure that log rotation, free disk space, and error reporting are handled outside the pager.
If the purpose is to limit output, do not use MORE as though it filters records. It does not select matching lines, redact secrets, normalize output, or make a report smaller on disk. For a restricted excerpt, use an appropriate search utility such as FIND and keep its match/no-match/error distinction intact. For data extraction, use a parser designed for the file format.
A pipeline itself may have limited behavior in a DOS shell compared with a modern shell. Keep commands simple, test the exact command processors and external utilities present, and avoid relying on command substitution, shell-specific pipefail semantics, or modern quoting rules. When a runbook needs reliable evidence, capture each producer output to a distinct file and record its exit status before opening the file with MORE.
Troubleshoot a pager that appears stuck
First decide whether MORE is waiting for the user or the producer. While displaying a file, the documented Space, N, and Q keys should advance, move to another file, or end the display. If input is coming through a pipe, the producer may be waiting, slow, or have emitted output that the pager has not yet displayed. Pressing arbitrary keys can obscure the state; use a known small source and a short command to reproduce the behavior.
Check that the file exists, is readable, and is not being rewritten concurrently. A very large wildcard set may take time to enumerate before the first page appears. A redirected or piped invocation may behave differently from an interactive file invocation. Confirm the command line, current drive and directory, path resolution, output destination, and exact MORE build before changing drivers or blaming the console.
If the display shows odd characters, verify code page and source encoding. If lines seem missing, compare the displayed result with a saved copy and inspect the original through another tool. If only one command’s pipe behaves badly, capture that command to a file first; this separates the producer’s output from the pager’s input path.
Acceptance checks for an operational runbook
Test MORE with a short file that spans several screens, includes a tab, a long line, a blank line, and representative non-ASCII bytes. Confirm the behavior of Space, N, Q, /Tn, wildcard input, redirection, and one relevant pipe. Run the test from both the current directory and a different directory using a full path. Repeat under the code page used by the intended system.
For a real diagnostic command, preserve the command text, source-file path, command exit result when relevant, output file, and a checksum or copy of important input. Verify that the saved report contains the information you intend to review; do not infer completeness from the last screen. MORE is reliable when its role is kept small: present text for a person, while storage and validation remain explicit, separate steps.
Related:
- How to Set Up a Development Environment on FreeDOS
- Running FreeDOS Today: Virtualization, Real Hardware, and Use Cases
Sources: