Useful Uses of cat

Original Article ↗ Hacker News Discussion ↗

Unix users are revisiting the old “useless use of `cat`” norm, arguing that starting pipelines with `cat file | ...` can actually improve modularity, readability, and interactive workflow, even if it spawns an extra process. Commenters contrast `cat`-driven pipelines with input redirection (`< file cmd`) and direct file arguments (`cmd file`), weighing performance, correctness edge cases, and how easily commands can be edited, reordered, or swapped (e.g., `cat` → `zcat` or `curl`). While purists still advocate minimizing redundant processes in scripts, many conclude that in day‑to‑day shell use the ergonomic benefits of `cat` often outweigh theoretical inefficiencies.

Modularity vs “useless use of cat”

  • Many defend starting pipelines with cat file | ... as a clean way to model “data source → transformations,” making it trivial to swap cat for zcat, curl, etc.
  • Others argue the article over-abstracts: splitting “turn filename into bytes” into its own process is a thin “responsibility.” Redirection (< file cmd) already decouples source from processing.
  • Some say cat makes pipelines more composable and mentally consistent; critics respond that modularity is not improved over using built-in file arguments or redirections.

Shell syntax, redirection, and readability

  • A lot of discussion centers on cat file | cmd vs <file cmd vs cmd <file.
  • Several point out POSIX shells let redirections appear anywhere in the simple command, e.g. <access.log head -n 500 | grep mail | perl ....
  • Opinions differ on readability: some find <file cmd elegant and symmetric (<infile cmd >outfile), others find it visually ugly and harder for their eyes to scan than cat infile | cmd.
  • There’s debate over whether redirection is a “pipeline step” conceptually or mere shell syntax.

Performance, correctness, and scripting concerns

  • One camp says “useless cat” is mainly pedagogical: it reveals misunderstanding and adds an unnecessary process and data copy, which can matter in scripts, large files, or on slow platforms.
  • Counterpoint: for most real workloads, fork/pipe overhead is noise; correctness and readability matter more, and shellcheck’s UUoC warnings can be more nagging than helpful.
  • Some note that passing a filename allows programs to inspect the file descriptor (TTY detection, buffering, color, etc.), which a cat pipe can obscure. Others view these cases as niche.

Interactive workflows and ergonomics

  • Many justify cat as an interactive convenience: they start with cat file, then press up-arrow and prepend | grep ..., | head ..., etc., iteratively refining filters.
  • Suggestions appear for faster history use: !$, $_, Alt+. and other readline/vi-mode tricks, plus zsh features like $READNULLCMD and process substitution.
  • Some prefer always beginning with <input X | Y | Z >output so input redirection stays stable while adding/removing stages.

Alternative tools and lesser-known features

  • Mentions of tac, rev, nl, zgrep, lesspipe, xargs, awk, perl, sed, and diffing with process substitution (diff -aui <(xxd a) <(xxd b)).
  • cat -A, cat -n, here-docs, using cat as an identity transform in functions, as a simple editor (cat > file), or as a template injector (cat - inside heredocs) are highlighted as genuinely “useful uses.”

Humor and tangents

  • Numerous cat (animal) jokes, book references, and physics/linear-algebra gags appear, plus meta-comments about HN pedantry and the social dynamics of “UUoC policing.”