DECTST Invoke Confidence Test

DECTST asks the terminal to run its diagnostics. In the VT510 manual the first parameter is always 4, and each one after it selects a test, so that several can be run at once:

DEC STD 070 leaves the tests to each product. It lists DECTST among its documented exceptions, as CSI Ps y with a default of 0, on p. D-11, and says what the least a terminal may do is:

The minimal implementation of this control is to execute the Reset to Initial State (RIS) control, and to return a “Device Ready” indicator by default.

The “Device Ready” indicator is the answer to a device status report, CSI 5 n, which a host sends afterwards to learn how the tests went. Beyond that, DEC STD 070 promises nothing: “after execution of this control the state of the device should be considered to be UNDEFINED. NO RECOVERY IS GUARANTEED WHEN THIS CONTROL IS EXECUTED.” So there is no case for what DECTST does to the screen. Its algorithm starts with RIS, but a terminal that runs real tests may leave anything behind them.

xterm does not implement DECTST. Its parse table sends a control sequence ending in y back to the ground state with nothing done (VTPrsTbl.c). The cases follow xterm, as the sources page explains: the parameters are not displayed, and the terminal answers “Device Ready” afterwards. Those are also all that DEC STD 070 pins down, so a terminal that did run its tests would pass them too.

Not in libghostty-vt

libghostty-vt has no case for a control sequence ending in y, so it ignores DECTST, as xterm does. That passes both cases, which check only what is true whether or not a terminal runs a test.

Validation

DECTST-1: The parameters are not displayed

\e[4;1y   # the power-up self test
X

|X____|
cursor 1,2

DECTST-2: Ready afterwards

\e[4;0y   # all tests
\e[5n     # how did they go?

|_____|
reply \e[0n