Skip to main content
ansicode

DECALN — Screen alignment pattern (ESC # 8)

Fill the entire screen with capital `E` glyphs — DEC's CRT alignment test, the canonical 'is the page buffer wired up right' smoke test.

Byte forms

Every common string-literal form so you can paste-and-search either direction.

\\x1b[\x1b#8
\\033[\033#8
\\e[\e#8
ESC [ESC # 8
hex1b 23 38

Description

Screen Alignment Test. A **C1-class** escape sequence (no CSI, no parameter — `ESC # 8`, three bytes total) that fills every cell on the active page with the ASCII character `E` (0x45). Originally a hardware diagnostic on DEC VT100 series: the bright uniform `E` pattern made it trivial for a service technician to verify that the CRT's electron beam was deflecting linearly (every `E` should be the same size and shape regardless of position) and that the page memory was addressing all rows / columns correctly (no dropped cells, no row repeats). On software emulators today, it's mostly used by terminal-emulator test suites — vt100/vt220/xterm compatibility tests emit `ESC # 8` to verify that the emulator's grid is correctly sized and addressable. Key behavioural notes: - The fill **respects the current page size** — if you've enabled DECCOLM 132 (`\x1b[?3h`, slug `deccolm`), DECALN paints 132 columns of `E`; in 80-col mode, 80 columns. - **All SGR attributes are reset** for the fill — every painted cell uses the default fg/bg with no bold/italic/underline. This makes DECALN a kind of 'visual sgr-reset+clear' in one byte. - The cursor is **homed** to row 1 / column 1 after the fill. - DECALN ignores DECOM (origin mode) and scrolling regions — it always paints the entire page, edge to edge. Modern emulator support is uneven: xterm and mlterm implement it faithfully (the test suites depend on it); kitty / wezterm / ghostty / alacritty mostly implement it (it's cheap — one byte to recognise, one screen fill to execute) but a few omit it. Linux fbcon and Windows Terminal silent-ignore. Use cases: emulator test suites, retro / VT100-faithful screensavers, debugging cell-grid issues during emulator development. Don't ship to end users — it instantly destroys whatever was on screen.

Spec citation: DEC VT100 (DECALN) / xterm-ctlseqs

Parameters

Examples

bash
printf '\033#8'   # fill screen with E\nsleep 2\nprintf '\033[2J\033[H'   # clear screen + home cursor — back to normal
python
import sys, time\nsys.stdout.write('\x1b#8')   # smoke test the grid\nsys.stdout.flush()\ntime.sleep(0.5)\nsys.stdout.write('\x1b[2J\x1b[H')   # clear
go
// Cheap emulator-correctness probe: DECALN, then DSR cursor-pos, expect (1,1):\nfmt.Print("\x1b#8")\nfmt.Print("\x1b[6n")   // → \x1b[1;1R if homing worked
javascript
process.stdout.write('\x1b#8')   // alignment pattern\nprocess.stdout.write('\x1b[2J\x1b[H')   // restore clean state
c
fputs("\x1b#8", stdout);    /* fill */\nfputs("\x1b[2J\x1b[H", stdout);  /* clear + home */

Terminal support

xterm
yes
Linux console (fbcon)
no
macOS Terminal.app
yes
iTerm2
yes
Windows Terminal
no
cmd.exe / ConPTY
no
kitty
yes
alacritty
yes
WezTerm
yes
Ghostty
yes
GNOME Terminal
partial
Konsole
yes
tmux
no
GNU screen
no

Related sequences

In the family cookbook

ESC cookbook · 4. Double-width / double-height lines + alignment test — `\x1b#3-#6` and `\x1b#8`