Entering text in the terminal is complicated

Original Article ↗ Hacker News Discussion ↗

Terminal text input, from basic line editing to advanced readline keybindings, turns out to be far more complex and inconsistent than many users expect, even for experienced developers. Commenters compare shells, editors, and operating systems, noting how differing defaults, licensing constraints (like GPL-licensed readline), and historical TTY behavior create a fragmented experience that’s hard to discover and learn. Some see powerful text-based interfaces as essential for control, automation, and debugging, while others argue that this complexity and reliance on the command line is a major barrier to wider adoption of Linux-style systems on the desktop.

Terminal UX & Learning Curve

  • Many see terminal input and copying/pasting as a major barrier, especially for beginners and Windows users; restricted server environments amplify frustration.
  • Others report that standard Linux terminals (e.g., Ubuntu) feel “perfect” once familiar: arrows, tab, Ctrl+R/C/D/W, etc.
  • Several long‑time users admit they only recently learned about readline shortcuts or didn’t know the term “readline” at all, highlighting poor discoverability.
  • Some criticize the idea that it could take 15 years to learn Ctrl+A/E; others say that’s realistic if you never explicitly study terminal ergonomics.

Keybindings, Modes & Shell Features

  • Emacs-style shortcuts (Ctrl+A/E/K/Y/T, etc.) are widely available in shells and even general macOS text fields.
  • Vi mode in shells (set -o vi, zsh, ksh, etc.) has fans, but even dedicated Vim users sometimes prefer emacs-style bindings on the command line.
  • Useful tricks discussed:
    • Ctrl+X Ctrl+E / Alt+e / v in vi mode / fc to edit the current or previous command in $EDITOR.
    • History search with Ctrl+R, stepping with Ctrl+O, and word/line deletion with Ctrl+W/Ctrl+U.
  • Opinions diverge on modifying defaults vs memorizing shortcuts. Some prefer Home/End or arrow keys; others remap Caps Lock to Ctrl.

TTY Mechanics & Escape Sequences

  • Several comments explain canonical (“cooked”) vs raw mode, fgets() behavior, line editing provided by the kernel TTY layer, and how programs like shells or TUIs override this.
  • Tools like stty can reconfigure input behavior; stty sane/reset help recover from “mangled” terminals.
  • There is discussion of ANSI/VT100 escape sequences, termios flags, and the messy diversity of terminal emulation and feature detection.

Copy/Paste & Terminal Behavior

  • On Linux, the Ctrl‑Shift‑C/V convention is widely disliked by some, who prefer the Windows Terminal behavior where Ctrl‑C copies when text is selected and sends SIGINT otherwise.
  • Others prefer “copy on select” plus middle‑click paste, or remap terminals (e.g., kitty, WezTerm, iTerm2) to more “natural” shortcuts.

CLI vs GUI, Linux Adoption & Alternatives

  • One view: the terminal’s complexity “condemns” desktop Linux to low market share; most users just want appliance‑like systems and avoid terminals entirely.
  • Counter‑view: most users on Windows/macOS also rarely touch the CLI; Linux’s main problem is OEM preinstall, not terminals.
  • Several stress that CLIs are invaluable for recovery, debugging, scripting, and precise control, even if GUIs cover common tasks.
  • Proposed alternatives include chat‑like or notebook‑style interfaces, richer structured terminals (e.g., Warp, IPython‑like shells, Plan 9/Oberon‑inspired UIs), and improved GUI tooling around system management.

Licensing & Readline

  • The GPL license on GNU readline is seen by some as a UX hindrance (blocking non‑GPL programs from using it); others argue this was an intentional strategy to encourage GPL adoption and prevent one‑way extraction of value.

Command Discovery & Aids

  • Users struggle with remembering commands and options; suggested aids include apropos, rich completion shells like fish, history search tools like fzf, personal notes/aliases, and even shell‑integrated LLM helpers.