Skip to content
FreeDOSDeep Dive Published Updated 7 min readViews unavailable

FreeCOM Interactive Command-Line Editing: History, Cursor Keys, and Completion

Use FreeCOM's interactive history, editing, and filename completion safely, while recognizing compile-time input modes and shell-specific behavior.

FreeCOM includes interactive command-line editing features that many DOS users associate with DOSKEY: recalling previous commands, moving within an unsubmitted line, switching between insert and overwrite, and completing a filename with Tab. In a standard FreeDOS installation, the DOSKEY help page says these functions are built into the command interpreter, so a separate DOSKEY executable is not required for the documented behavior.

That description needs an important qualification. FreeCOM’s own documentation distinguishes a standard-input editor from an enhanced input editor, and says the choice is made at compile time. Enhanced mode supports command history and filename completion; standard mode has a much smaller key contract and may recall only the last line in certain circumstances. A FreeDOS prompt that lacks a feature is not necessarily broken: it may be running a different FreeCOM build or configuration.

Identify the shell before diagnosing keys

At a DOS prompt, command behavior belongs to the active command interpreter, not to a universal DOS keyboard service. FreeCOM is FreeDOS’s command interpreter, but another shell or a differently built FreeCOM can expose different behavior. Start with VER, inspect COMSPEC, and consult COMMAND.COM /? or the installed help files. Do not infer a build feature from the presence of FreeDOS alone.

FreeCOM’s feature documentation says the editing implementation is selected at compile time. It also lists a PLAINEDT distribution variant that uses plain command-line editing rather than the enhanced editor. Consequently, a support note should record the actual shell binary and distribution package, not merely say “FreeDOS 1.x.” If a key table matters to an operational runbook, check it on the target binary.

Practical enhanced-mode key map

The FreeDOS DOSKEY command reference lists the familiar high-value keys: Up and Down recall history, Left and Right move within a line, Home and End move to its edges, Insert toggles insert/overstrike, and Tab completes a current word as a filename. Pressing Tab twice displays matching files according to that page. FreeCOM’s more detailed table also describes Delete for the character at the cursor and Escape for clearing the current line.

Use these features as editing conveniences, not as command validation. A recalled command is a copy of prior text; its paths, drive letters, switches, and destructive effects may no longer be correct. Before pressing Enter, inspect the whole line, especially after moving the cursor or accepting a completion. Tab completion can select a filename that is syntactically valid but semantically wrong, and it does not prove that the file is safe to execute or overwrite.

Up        Recall a prior command line
Left/Right Move within the current input line
Home/End  Move to the start or end of the line
Insert    Toggle insert and overwrite behavior
Tab       Complete a filename candidate
Tab twice Show matching filename candidates
Esc       Clear the line in enhanced mode

The key behavior above reflects the cited FreeDOS/FreeCOM documentation, not every DOS clone, terminal, keyboard driver, or emulator. Enhanced input processes keys itself, so BIOS keyboard translation, a remote-console layer, or an emulator’s scan-code handling can affect what FreeCOM receives. If a key is missing or produces an unexpected character, test the same shell locally and in the target terminal before changing system-wide keyboard configuration.

Understand standard versus enhanced input

FreeCOM’s feature page states that standard input calls a DOS input function, while enhanced input processes each key itself. Standard mode does not offer full command history or file completion; the docs mention a last-line exception in some circumstances. Enhanced mode supports history and filename completion. Because the choice is made at compile time, there is no universal runtime switch guaranteed to convert every installed shell from one mode to the other.

This distinction helps isolate troubleshooting. If Enter accepts commands and basic editing works but Up does not traverse prior commands and Tab does not complete names, first identify the FreeCOM build. If enhanced mode should be present, test in a simple local console with a short known filename. A problem limited to a particular emulator or remote console points to input translation or terminal integration rather than necessarily to FreeCOM’s command parser.

The shell’s input editor is separate from the behavior of programs that read standard input. A full-screen DOS application may take over keyboard input; a program can also change display or keyboard modes. Return to the shell before evaluating its history and completion. Do not press shell editing keys into a recovery or installer prompt unless that program’s own documentation says they are valid.

History is convenient, not durable audit logging

History is meant to make interactive re-entry easier. It is not a reliable command audit trail, a batch script, or a record of the command’s result. The documentation describes recalling and re-executing prior lines; it does not promise persistence across reboot, tamper resistance, timestamps, user attribution, or complete capture. For a repeatable operation, place reviewed commands in a controlled batch file and preserve its source and output separately.

Before re-running a destructive command from history, revalidate the target drive and current directory. DOS drive state includes per-drive current directories; the same relative path can resolve differently after a CD, drive change, menu selection, or removable-volume swap. A visually identical recalled line can therefore act on a different object. Prefer explicit drive and path names in a maintenance procedure, while still validating the media label and backup.

History also has an information exposure concern. A command line can include filenames or other values that should not remain visible to a later operator. Do not type credentials, serial numbers, or secrets into interactive command arguments merely because a modern terminal normally masks or scrubs them. FreeDOS command history should not be treated as a secret store; use a purpose-built credential mechanism where one exists.

FreeCOM exposes additional shell state through commands such as HISTORY and MEMORY. The FreeDOS help page for MEMORY explains that history occupies part of the shell’s context storage, and that the displayed limits and output can vary while FreeCOM internals change. This helps explain why an older line may disappear or why history capacity is not unlimited. Do not promise an operator that every command from a long session remains available; preserve important procedures in a reviewed file instead.

This context storage is distinct from the DOS environment segment. Increasing a shell’s environment size with a COMMAND.COM option does not necessarily increase every internal context allocation or history limit. Check the actual MEMORY report and the documentation for the FreeCOM build. If resource pressure or history behavior matters, capture the output from the target shell and test after a fresh boot; a second nested shell can have its own context and memory use.

Validate the actual keyboard contract

Use a harmless scratch directory containing several filenames with a shared prefix. At the prompt, type the prefix, press Tab once, observe the completion, and press Tab twice only if you intend to display candidates. Recall a non-destructive command with Up and Down, edit it without submitting, toggle Insert, and verify that Escape clears only the current line. Confirm the prompt returns to a known drive and directory afterward.

If one operation differs, collect evidence before making changes: shell version/build package, emulator or hardware, keyboard layout, active console driver, and whether the input path is direct or remote. Test ordinary ASCII keys, arrows, Home/End, Insert, Delete, Escape, and Tab independently. This separates missing enhanced-editor support from a single scan-code issue or an application that still owns the keyboard.

For automation, do not simulate interactive key sequences when a batch command or documented application interface is available. Completion is inherently dependent on the current directory contents; history depends on the previous session. A batch file with explicit paths and checks is more reproducible. Interactive editing remains valuable for maintenance, but its state should not silently become part of an unattended deployment plan.

Related:

Sources:

Comments