Some terminal frustrations

Original Article ↗ Hacker News Discussion ↗

Skill Issues vs. Design Problems

  • One camp frames most terminal pain as “skills issues”: Unix tools are old, deeply embedded, and powerful; users should invest in learning them (man, info, readline, job control, etc.).
  • Others push back that this becomes gatekeeping: dismissing legitimate UX problems as laziness, ignoring empathy and modern expectations, and treating memorizing flags as moral virtue.
  • There’s tension between respecting historical constraints (80x24, tiny RAM) and acknowledging that hardware and user expectations have changed.

Editing, Copy/Paste, and the TTY Model

  • Many want terminals to behave like normal text fields: click-to-edit commands, GUI-standard shortcuts for copy/paste, ESC to reliably “escape” a program.
  • Replies note this is mostly about shells/REPLs, not terminal emulators: the screen is a log, input is separate. Readline, zsh, fish, rlwrap already support cursor editing; some terminals support mouse placement.
  • Copy/paste shortcuts are a major annoyance: Ctrl-C vs SIGINT, Ctrl-Shift-C/V, Command-C/V on macOS, Windows-style behaviors, X11 primary selection (select + middle-click) vs “clipboard”.
  • Some describe key remapping setups (Super/Command as copy/paste, Ctrl reserved for terminal signals) as partial fixes.

History, Discoverability, and “Second Brains”

  • Remembering commands/flags is widely seen as the real bottleneck.
  • Tools like fzf, Atuin, mcfly, hishtory, zsh+Ctrl‑R, long HISTSIZE, and project-scoped history are praised as “second brains” for complex commands.
  • Others prefer curated “playbooks” over raw history search.
  • Discoverability of tools and features is poor; people report learning via random tips over years. Sites like Terminal Trove and cheat.sh/tldr try to fill this gap.
  • Several describe using LLM-based helpers (llm, gh copilot, how.sh, Pal) to generate commands or explain errors directly in the terminal.

CLI Argument Conventions and Help

  • Strong sentiment that --help (and usually -h) should always work and do nothing but print help. Programs that reject --help or distinguish -help/--help are called hostile.
  • Complaints about:
    • Inconsistent flags (-h = help vs host vs halt).
    • Single-dash long options (common in Go/Java tools, find).
    • Tools that spew pages of help on minor errors vs concise diagnostics.
  • Some argue man pages are the true “standard”; others note many tools ship no man pages, so in-band help is essential.
  • Writing good CLIs (clear --help, good defaults, meaningful errors, examples) is viewed as a serious UX skill.

Colors, Terminfo, and Terminal Standards

  • Hard-coded ANSI escapes (bypassing terminfo) are blamed for broken colors and capabilities across terminals and SSH hops.
  • Proposed direction: use terminfo or XTGETTCAP-like queries to detect capabilities in-band; never output escape codes when stdout isn’t a TTY.
  • Frustration that many developers don’t even know terminfo exists; terminal knowledge seen as a “lost” foundation.

Alternative Tools and Ecosystems

  • Frequent recommendations: tmux (with tweaks like inheriting current directory), zellij, fzf, vivid for LS_COLORS, eza, fd, ripgrep, bat, ugrep, Atuin, Emacs/ansi-term, Lightkeeper GUI, and more.
  • PowerShell sparks a split: some praise piped objects and structured serialization; others find it verbose, non-portable, and conceptually misguided compared to plain-text Unix pipelines.

Philosophy and Legacy

  • Some celebrate the resilience and composability of the “dumb” text-only stack (SSH → shell → tmux → editor) and its backward compatibility, even with 1980s hardware.
  • Others argue the terminal-as-emulator model is archaic and blocks better interaction designs, but recognize replacing it without breaking everything is extremely hard.