Skip to content
FreeDOSDeep Dive Published Updated 6 min readViews unavailable

FreeDOS CTTY: System-Wide Console Routing Beyond Stream Redirection

Understand how FreeDOS CTTY changes console routing, why it differs from redirection, which programs bypass it, and how to test serial or NUL sessions safely.

CTTY changes the terminal device DOS treats as its console. That is a different operation from redirecting a command’s standard input or output: it changes the system console route, including console-oriented DOS interactions, rather than merely replacing one or more handles for a child process. This distinction matters when operating FreeDOS over a serial terminal, suppressing console output in an unattended sequence, or diagnosing a program that still writes to the physical screen after the shell has redirected output.

The FreeDOS command reference describes CTTY as an internal command that changes the console device for the whole system. It lists PRN, LPT1 through LPT3, CON, AUX, COM1 through COM4, and NUL as accepted device names, while also warning that a console must support both input and output. The exact effect depends on both FreeCOM and the active kernel. Do not treat a successful command return as proof that every program now uses the selected device.

Console routing is not the same as handle redirection

DOS applications can reach text input and output through different interfaces. A program using a standard handle may be affected by shell syntax such as >, <, or 2>. Console-specific DOS functions may resolve through the logical console device. BIOS calls and direct video-memory or keyboard-controller access form still other paths. A shell redirect changes a stream binding; CTTY changes which device is used for console-oriented work. Neither operation can intercept software that bypasses the layer it changes.

That is why the two techniques solve different problems. A filter such as TYPE FILE.TXT >LOG.TXT redirects the command’s output stream. A remote operator session needs a terminal device that carries both keystrokes and display output, which is the use case for CTTY AUX or a COM device. A batch file that sends its ordinary output to a file can still have diagnostics written to a separate handle, while console functions may continue through the system console. Conversely, a full-screen application that writes directly to video memory can remain on the local monitor even after CTTY AUX.

This is also why redirection and CTTY can be layered. When the active console is NUL, explicitly naming CON in a redirection can direct a command back to the currently assigned console device where the shell and kernel support that route. FreeDOS documentation gives ECHO ... >CON and PAUSE >CON as examples. Such a technique must be tested with the installed shell and kernel; it does not turn direct BIOS output into a redirectable stream.

Use a bidirectional endpoint

The selected terminal is not simply an output sink. Console interaction includes reading input as well as writing output. The FreeDOS help therefore cautions against assigning a unidirectional device such as PRN as the console. NUL is a special case: it accepts console output by discarding it and supplies no useful keyboard input. It is appropriate only for a sequence that is known not to prompt or block for interactive input.

AUX is commonly associated with the first serial port on PC-compatible systems, but the FreeDOS help says it is usually COM1, not that every machine maps it identically. A serial terminal workflow therefore depends on the device map, UART configuration, cable or virtual-serial wiring, and the other endpoint’s settings. Establish and test the COM port before changing the console. For example, FreeDOS MODE documents serial parameter forms such as:

MODE COM1: 9600,N,8,1
MODE COM1: /STATUS

This only configures the serial port parameters recognized by the installed MODE and driver stack. It does not configure a remote terminal emulator, guarantee flow control, or prove that the cable is wired correctly. Validate both directions with a harmless test before using the serial path as the only control surface.

A controlled serial-console test

Keep a local keyboard available and make changes from a boot profile that can be recovered. First record the current kernel, shell, COM port, and any serial or device drivers. Confirm that the remote terminal is attached to the intended port and uses matching baud rate, parity, data bits, and stop bits. Then test the port with a known two-way serial utility or a second machine before assigning it as the console.

After the link itself works, switch the console from an interactive prompt:

CTTY AUX

Check both input and output from the remote endpoint. Run a harmless internal command, enter a deliberately invalid command to observe diagnostics, and test a program that uses normal DOS console routines. Then test any real workload separately. If only command output appears but keystrokes do not, the route is not operational as a console. If the shell works but a full-screen program remains on the local display, it is likely using BIOS or direct hardware access rather than the DOS console device.

Restore the local console through the remote session while it remains available:

CTTY CON

Do not assume a failed serial command has restored the local device. Keep a written recovery sequence and a boot profile that omits the CTTY change. On a test machine, verify the recovery path before depending on serial access for an unattended server-like workload.

Treat NUL routing as a bounded batch operation

The FreeDOS command reference documents a sequence such as:

CTTY NUL
REM Run only commands known not to request console input.
CTTY CON

This suppresses console messages, including errors sent through console output paths. It does not make commands succeed silently in a transactional sense. A command may still fail, wait for input that never arrives, or leave partial work behind. When the sequence is intended for repeatable automation, capture each command’s exit status where the shell supports it, redirect file output explicitly, and write a completion marker only after all steps have succeeded.

Never wrap an unknown installer, disk utility, or interactive repair command in CTTY NUL to make its output disappear. Prompts can be hidden or unreadable, and some applications do not handle end-of-input correctly. Use a disposable image for tests involving installation or repair, and keep the local console accessible until the final command has restored CON.

Diagnose which I/O layer a program uses

When a program ignores CTTY or a shell redirect, classify its path before changing configuration again:

  1. Test ordinary input/output through DOS handles with a small, known program.
  2. Compare a console-specific program that uses DOS console services.
  3. Compare a text-mode full-screen program that may use BIOS video services.
  4. Check whether the application writes directly to video memory or polls keyboard hardware.
  5. Repeat with a different kernel or emulator only after saving the original result.

An observed local-screen write is evidence that the program may bypass the changed device, not evidence that CTTY did nothing. A prompt that vanishes into NUL is also not evidence that a process completed. Record the application, kernel build, shell, device mapping, exact CTTY command, and whether the input and output paths were independently tested.

CTTY is most useful when treated as a system console-routing control with explicit boundaries. It can expose DOS console interaction through a bidirectional terminal or suppress routine console traffic in a carefully bounded sequence. It cannot transparently virtualize all display hardware, repair a misconfigured serial link, or replace per-handle redirection. A successful deployment proves the actual application path, both input and output, and the recovery path on the target FreeDOS configuration.

Related:

Sources:

Comments