Why does the terminal show "^[[A" "^[[B" "^[[C" "^[[D" when pressing the arrow keys in Ubuntu?

Understanding Arrow Key Output: Why Your Terminal Shows ^[[A, ^[[B, ^[[C, ^[[D

Explore the reasons behind the cryptic ^[[A, ^[[B, ^[[C, ^[[D sequences when pressing arrow keys in your Ubuntu terminal, and learn how terminals interpret these control codes.

Have you ever been typing in your Ubuntu terminal, perhaps in a text editor like nano or during a command-line interaction, and accidentally pressed an arrow key, only to see strange characters like ^[[A, ^[[B, ^[[C, or ^[[D appear instead of the cursor moving? This common phenomenon can be confusing, especially for new Linux users. This article will demystify these sequences, explaining what they are, why they appear, and how your terminal environment handles them.

The Nature of Terminal Control Sequences

Terminals, whether physical or emulated, communicate with programs using a stream of characters. When you press a standard key like 'a' or '1', the ASCII code for that character is sent. However, special keys like arrow keys, function keys, Home, End, Page Up, Page Down, etc., don't have a single, dedicated ASCII code. Instead, they send multi-character sequences, often starting with the Escape character (ASCII 27, represented as ^[, \e, or \x1b). These are known as control sequences or escape sequences.

flowchart TD
    User[User Presses Arrow Key] --> Keyboard[Keyboard Generates Scan Code]
    Keyboard --> OS[Operating System Translates Scan Code]
    OS --> TerminalEmulator[Terminal Emulator Receives Event]
    TerminalEmulator --> SendsEscapeSequence["Sends Escape Sequence (e.g., ^[[A)"]
    SendsEscapeSequence --> Program[Program (e.g., Shell, Editor) Receives Sequence]
    Program --> InterpretsSequence{Interprets Sequence?}
    InterpretsSequence -->|Yes| CursorMove[Moves Cursor/Performs Action]
    InterpretsSequence -->|No| PrintsCharacters[Prints Raw Characters to Screen]
    PrintsCharacters --> UserSees["User Sees ^[[A, ^[[B, etc."]

Flow of an arrow key press from user to terminal output

Decoding the Escape Sequences

The sequences ^[[A, ^[[B, ^[[C, and ^[[D are specific types of ANSI escape codes, commonly used by xterm and compatible terminals. Let's break down what each part means:

• ^[: This represents the Escape character (ASCII 27). In many terminal displays, it's rendered as ^[ (caret followed by left square bracket) because ^[ is the standard notation for the control character ESC.
• [: This is a literal left square bracket character, indicating the start of a Control Sequence Introducer (CSI) sequence.
• A, B, C, D: These are the final characters that specify the action. In the context of arrow keys, they typically mean:
  • A: Up Arrow
  • B: Down Arrow
  • C: Right Arrow
  • D: Left Arrow

So, ^[[A literally means Escape then [ then A. When a program is designed to understand these sequences, it interprets them as commands to move the cursor. If a program doesn't understand them, or if the terminal is in a raw input mode where it's not processing special keys, it will simply print the raw characters to the screen.

echo -e "\x1b[A" # Simulates Up Arrow
echo -e "\x1b[B" # Simulates Down Arrow
echo -e "\x1b[C" # Simulates Right Arrow
echo -e "\x1b[D" # Simulates Left Arrow

Using echo -e to print ANSI escape sequences. Note: These will only move the cursor if your terminal is in a mode that interprets them, otherwise they might print raw characters.

Why Programs Interpret Them Differently

The key to whether you see the raw characters or a cursor movement lies in how the program you're interacting with (e.g., your shell, a text editor, or a custom script) handles terminal input. Programs like bash, zsh, vim, emacs, and nano are designed to be 'terminal-aware'. They use libraries like ncurses or readline which are specifically built to interpret these complex escape sequences and translate them into actions like cursor movement, scrolling, or command history navigation.

When you see ^[[A printed, it usually means one of two things:

1. The program is not expecting interactive input: You might be in a simple cat command, or a script that's not designed to handle interactive cursor movement. It's simply echoing whatever it receives.
2. The terminal is in a 'raw' mode: Sometimes, especially during debugging or when a program crashes, the terminal might revert to a mode where it doesn't process special keys, passing them directly to the output. This is less common in modern interactive shells but can happen.

Terminal Emulators and Terminfo

Modern Linux systems use a terminfo database (or the older termcap) to describe the capabilities of various terminal types. This database contains entries for different terminals (e.g., xterm, linux, vt100) and defines the escape sequences they send for special keys, as well as the sequences required to perform actions like clearing the screen or moving the cursor. When a program starts, it typically checks the TERM environment variable to determine the terminal type and then consults terminfo to understand how to communicate with it.

This standardization allows programs to be written once and work across many different terminal emulators, as long as the terminfo entry is correct.

echo $TERM
infocmp $TERM | grep kcuu1

Checking your current terminal type and the terminfo entry for the 'key cursor up' sequence (kcuu1). You'll likely see \E[A or \x1b[A.

In summary, the ^[[A sequences are not errors but rather the raw signals your arrow keys send to the terminal. When a program is equipped to interpret these signals, it translates them into the expected cursor movements. When it's not, you see the underlying control characters. Understanding this mechanism helps demystify a common terminal quirk and highlights the intricate communication between your keyboard, terminal, and the applications you run.