Does REP (\x1b[Pn b) repeat the most recent control sequence, the most recent byte, or the most recent printing character?

Strictly the most recent *graphic character* — the one that updated the terminal's display. Control codes (CR, LF, BS), SGR sequences, cursor moves, and whitespace are skipped; if no graphic character has been emitted yet, REP is a no-op. printf '─\033[79b' prints 80 ─; printf '\033[31m\033[79b' (SGR then REP, no graphic character between) prints nothing. The spec language is ECMA-48 §8.3.103: "REP causes the preceding graphic character to be repeated".

Why isn't REP supported on macOS Terminal / iTerm2?

Apple's Terminal.app and iTerm2 are historic VT100-family emulators built before REP was widely deployed — REP was an xterm extension (since X11R5) that VT100 didn't define. Apple's parser routes the final byte b to a no-op rather than the REP handler, so \x1b[5b prints nothing instead of repeating. The portable pattern: probe XTGETTCAP rep (\x1bP+q726570\x1b\\) at startup, fall back to a literal loop printf '─' x 80 if the cap is missing. Modern terminals (kitty, wezterm, Ghostty, foot, alacritty, mintty, Windows Terminal ≥ 1.18) implement it; Linux console implements it too (via the in-kernel console_codes(4) VT subset).

REP — Repeat Preceding Character (CSI Pn b)

Repeat the most-recently-emitted printing character N times — a bandwidth-saver for runs of identical glyphs.

Byte forms

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

\\x1b[\x1b[Pnb

\\033[\033[Pnb

\\e[\e[Pnb

ESC [ESC [ Pn b

hex1b 5b <Pn> 62

Description

Repeat Preceding Character. Final byte b (0x62) prints the most-recent graphic character (the one that updated the terminal's display, NOT a control code or whitespace) Pn more times (default 1). If the previous emitted byte was a control or none-yet, REP is a no-op. Useful in narrow SSH links: drawing a horizontal rule of 80 ─ chars costs 80 multi-byte UTF-8 bytes (160-240 bytes) versus ─\x1b[79b (5 bytes + 4 control bytes = 9 bytes). Supported by xterm (since X11R5), kitty, wezterm, ghostty, alacritty, mintty, foot; Windows Terminal added support in 1.18+; iTerm2 doesn't support it. Apps that emit decorative box-drawing or progress-bar fills can preflight via XTGETTCAP for the rep cap before using it. Terminfo cap: rep.

Spec citation: ECMA-48 §8.3.103 (REP)

Examples

bash

# 80-char horizontal rule with minimal bytes:\nprintf '\xe2\x94\x80\033[79b\n'

python

import sys; sys.stdout.write('-\x1b[79b\n')   # 80 dashes

fmt.Print("-\x1b[79b\n")

javascript

process.stdout.write('-\x1b[79b\n')

printf("-\x1b[79b\n");

Used in

Real-world tools that emit this sequence — anchors the bytes to commands you've already used.

ANSI horizontal-rule emitters (CLI banners)Bash one-liners like `printf '\xe2\x94\x80\033[$((COLUMNS-1))b\n'` draw a full-width box-drawing rule with O(1) bytes regardless of terminal width — used by `gh pr view --comments`, `glab issue view`, and most modern CLIs over `seq` + `printf` loops
neovim screen redraw (when `set lazyredraw`)neovim batches buffer updates and emits REP for runs of identical glyphs (whitespace fill, undrawn-pane stubs) during the redraw flush — visible in `:set verbose=20` traces as `<Esc>[ Nb` clusters
fastfetch / neofetch ASCII art rendererDistribution logo ASCII renders use REP to compress runs of the same colour-block character (`█`) — a 60×40 logo shrinks from ~12 KB of UTF-8 to ~3 KB on terminals advertising the `rep` cap, with literal fallback otherwise
less progress bar / file-size column paddingless ≥ 600 uses REP to pad the bottom-line `:` prompt with spaces when the file size column is narrow — `\033[<N>b` keeps the screen redraw under 50 bytes per status update on a 200-column terminal
Windows Terminal 1.18+ test pattern generatorMicrosoft's `wt`-launched test pattern UI (Settings → Render → Test pattern) emits REP-heavy gradients to verify the renderer's batch handling — a regression in 1.21 that broke REP on truecolor cells was caught by this fixture

Frequently asked

Short answers to the questions developers actually search for this sequence.

Does REP (\x1b[Pn b) repeat the most recent control sequence, the most recent byte, or the most recent printing character?: Strictly the most recent *graphic character* — the one that updated the terminal's display. Control codes (CR, LF, BS), SGR sequences, cursor moves, and whitespace are skipped; if no graphic character has been emitted yet, REP is a no-op. printf '─\033[79b' prints 80 ─; printf '\033[31m\033[79b' (SGR then REP, no graphic character between) prints nothing. The spec language is ECMA-48 §8.3.103: "REP causes the preceding graphic character to be repeated".
Why isn't REP supported on macOS Terminal / iTerm2?: Apple's Terminal.app and iTerm2 are historic VT100-family emulators built before REP was widely deployed — REP was an xterm extension (since X11R5) that VT100 didn't define. Apple's parser routes the final byte b to a no-op rather than the REP handler, so \x1b[5b prints nothing instead of repeating. The portable pattern: probe XTGETTCAP rep (\x1bP+q726570\x1b\\) at startup, fall back to a literal loop printf '─' x 80 if the cap is missing. Modern terminals (kitty, wezterm, Ghostty, foot, alacritty, mintty, Windows Terminal ≥ 1.18) implement it; Linux console implements it too (via the in-kernel console_codes(4) VT subset).

Common typos / look-alikes

Wrong forms developers commonly paste from Stack Overflow that look right but aren't — with the canonical correction inline.

\x1b[5b expecting it to repeat the NEXT char 5 times\x1b[5b repeats the LAST graphic char already emitted 5 times — emit ─ THEN \x1b[5b
REP (Repeat) repeats the most recently emitted graphic character Pn more times. The character must already be in the output stream — REP does not buffer or look ahead. Idiomatic horizontal rule: printf '─\x1b[78b' (one ─ plus 78 repetitions = 79-cell rule). The most common bug is printf '\x1b[5b─' expecting ─────; you get nothing (or the previous character repeated 5 times, whatever that was). Document this in any TUI primitive: REP needs an antecedent.
REP a SGR-styled char and expect the SGR to repeat tooREP repeats GRAPHIC chars only — SGR escapes are skipped; if you sent \x1b[31mX, REP repeats X with the already-set red attribute
REP only repeats graphic characters (0x20–0x7E + UTF-8 graphic codepoints). Control sequences and escape clauses between the last graphic char and REP are not part of the repeated unit — REP looks back through the parser state to the last graphic char. Practical consequence: \x1b[31m─\x1b[5b produces 6 red ─ (the SGR sets state, ─ is the last graphic, REP makes 5 more — all painted with the currently-set red attribute because SGR is sticky). This is usually what you want for coloured rules but is surprising to first-time users.
REP after a wide-char (CJK / emoji) and miscount cellsREP advances Pn × wcwidth(last_char) cells — a ╳-rule with REP is fine, but emoji REP eats 2× cells per repetition
REP doesn't think in characters, it thinks in cells × wcwidth. Repeating a wide character (East Asian Wide / emoji presentation, wcwidth = 2) advances 2 cells per repeat. printf '🟢\x1b[10b' paints 11 emoji and advances 22 cells — pre-allocating 11 cells of horizontal space underflows by 11. Library authors building progress bars or sparklines with REP need to call wcwidth() on the antecedent and budget cells, not characters. Plain ASCII glyphs are safe; box-drawing glyphs in U+2500–U+257F are wcwidth 1 and also safe. Anything in U+1F000+ generally is not.

Terminal support

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

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