Skip to content
FreeDOSDeep Dive Published Updated 7 min readViews unavailable

FreeDOS EDLIN: A Safe Line-Editing Workflow for Text-Only Recovery

Use FreeDOS EDLIN's numbered-line model to inspect, edit, transfer, save, and verify configuration text when a full-screen editor is unavailable.

FreeDOS EDLIN is a line-oriented text editor with a small command interface. It remains useful when a machine has only a minimal console, when a full-screen editor is unavailable, or when a repair session needs an editor with very few dependencies. Its interface is not a miniature version of a graphical editor: commands address numbered lines, insert mode is terminated explicitly, and writing changes to disk is a separate decision from leaving the editor.

FreeDOS EDLIN is a project maintained as a functional clone of the classic DOS editor, but its prompt and some commands differ from historical MS-DOS implementations. The current FreeDOS documentation illustrates version 2.24 and lists commands such as insert, append, list, search, replace, move, copy, transfer, write, end, and quit. Do not assume a command or control character from an old DOS manual behaves exactly the same in the installed FreeDOS build. Run ? in the editor and confirm the version before editing a critical startup file.

Protect the file before opening it

An editor is a write-capable tool. Before changing FDCONFIG.SYS, FDAUTO.BAT, a database control file, or a program’s configuration, copy the original to a separate name on a known-good volume. Record the size and, if available, a checksum. If the machine is already failing to boot, preserve the boot media or image before rewriting any configuration.

COPY C:\FDCONFIG.SYS C:\FDCONFIG.BAK
EDLIN C:\FDCONFIG.SYS

The copy command itself has overwrite and text/binary modes; verify that the backup target does not already contain a needed earlier version. If a separate volume is available, store the backup there too. A backup on the same failing disk can be lost along with the source.

EDLIN opens an existing file or reports that a new file is being created. The * prompt is command mode. Entering a appends new lines at the end; i inserts before the selected/current line. While entering text, the prompt changes to :. A period on a line by itself ends the input block and returns to the * prompt. That period is editor control input, not part of the saved file.

Treat line numbers as the editing coordinate system

The l command lists lines with numbers and marks the current line with an asterisk. The current line is important because i inserts before a line, while a always appends at the end. Do not assume that the screen cursor position is the current line or that the editor is in input mode merely because text appears below the prompt. First list the relevant area, identify the line number, and then issue a small edit.

Typing a line number at the command prompt selects that line for replacement; EDLIN displays the existing text and accepts the replacement text. For a configuration file, this can be safer than retyping the entire file, but it still requires careful review. Copy the displayed line before editing, compare the result after the edit, and watch for missing quotes, colons, drive letters, or trailing arguments. If a replacement line is long, ensure it is not silently wrapped by the terminal display and saved with unintended characters.

EDLIN also has commands for copying or moving ranges of lines. The built-in help describes the move form as a start line, end line, and destination separated by commas. For example, the syntax resembles 3,5,1m to move lines 3 through 5 to a new location. Do not use range operations until you have confirmed the current line numbering with l; moving or deleting the wrong block can alter boot behavior. Test complex range commands on a disposable file first.

Search and replace with explicit scope

The editor’s help lists s for searching and r for replacing. FreeDOS EDLIN’s command syntax supports line ranges and optional confirmation behavior. Because the exact delimiter conventions and prompts can differ from older EDLIN versions, consult the installed ? output before using a search/replace expression on a production file. Use a narrow line range where possible, and list the surrounding lines before and after the replacement.

Do not replace a short token globally when it can occur in unrelated paths or arguments. Changing C: to D: may be intended for one device line and harmful in every other occurrence. Search for a distinctive full value, then inspect the number of matches. If the file has only a few lines, editing each line explicitly is often less error-prone than using a broad replace command.

When moving configuration blocks, preserve directive order. For example, a device driver may need to be loaded before another component that depends on it. EDLIN does not understand FreeDOS’s boot semantics; it only rearranges text. Validate the completed file against the system’s documentation and keep a known-good boot menu entry or alternate configuration file available.

Save, write, and quit are distinct actions

The help lists w to write the edited contents and e to end the session by writing and quitting. q quits and may prompt if changes have not been saved. The distinction is operational: do not assume that leaving the editor automatically saves every change, and do not answer a confirmation prompt reflexively. After w, read the file again using EDLIN’s list command or another viewer, then compare it with the intended lines.

For a cautious edit, keep the editor session short and save only after reviewing the entire relevant region. Use q without saving if the experiment is wrong and the original backup is intact; read the prompt carefully to avoid discarding or saving unintentionally. Once written, exit and reopen the file to verify that the saved bytes reflect what you intended. A visual review before the write is not a post-write verification.

Do not edit the sole copy of an irreplaceable file. EDLIN’s t transfer command can bring text from another file into an edit buffer; copying sections from a trusted backup can be useful, but verify line endings and resulting content. Avoid assuming that transfer is a byte-for-byte merge or that it preserves all metadata. For binary files, use a binary-aware tool, never a text editor.

Keep repair sessions narrow and reproducible

An EDLIN repair record should include the filename, backup location, file size, editor version, exact lines changed, save command used, and validation performed. If the change is to a boot file, preserve the previous version under a filename that the startup process will not accidentally treat as another active configuration. Keep the recovery copy on removable or separately imaged media if disk failure is part of the incident.

After modifying CONFIG.SYS or FDCONFIG.SYS, test by booting the intended profile and watch each driver message. After modifying a batch file, run it in a disposable test environment with echoed commands before suppressing output. After changing an application configuration, launch the application and verify the actual feature affected by the setting. An editor reporting that it wrote a certain number of lines does not prove the system accepts the content.

EDLIN’s numbered-line workflow can be especially useful in a serial console or constrained recovery environment, but it is not a parser or validator. It cannot tell whether a DOS directive is valid, whether a path exists, or whether two startup lines conflict. Treat text editing and semantic testing as separate steps. If the change affects a boot path, preserve a recovery boot option before restarting.

A repeatable minimal editing procedure

  1. Make a verified backup to a separate filename or medium.
  2. Open the exact file with EDLIN and inspect the version/help output.
  3. List the relevant lines and note their numbers before editing.
  4. Apply one small change, then list and review the modified region.
  5. Save with w or use the documented write-and-exit command only after review.
  6. Reopen the saved file, compare it with the intended content, and test it in the real runtime.
  7. Keep the backup until the system has booted or the application has passed its acceptance test.

This procedure is slower than blindly editing several lines at once, but it makes each state transition visible and reversible. On a production or recovery machine, that clarity matters more than typing speed. EDLIN should be a deliberate editor choice, not the only remaining copy of a repair plan.

Related:

Sources:

Comments