Usos úteis de cat

Artigo original ↗ Discussão no Hacker News ↗

Usuários de Unix estão revisitando a velha norma de “uso inútil de `cat`”, argumentando que iniciar pipelines com `cat file | ...` pode, na verdade, melhorar a modularidade, a legibilidade e o fluxo de trabalho interativo, mesmo que isso crie um processo extra. Os comentaristas contrapõem pipelines centrados em `cat` com redirecionamento de entrada (`< file cmd`) e argumentos diretos de arquivo (`cmd file`), avaliando desempenho, casos-limite de correção e quão facilmente comandos podem ser editados, reordenados ou trocados (por exemplo, `cat` → `zcat` ou `curl`). Embora os puristas ainda defendam minimizar processos redundantes em scripts, muitos concluem que, no uso cotidiano do shell, os benefícios ergonômicos de `cat` frequentemente superam as ineficiências teóricas.

Modularidade vs “uso inútil de cat”

  • Muitos defendem iniciar pipelines com cat file | ... como uma forma clara de modelar “fonte de dados → transformações”, tornando trivial trocar cat por zcat, curl, etc.
  • Outros argumentam que o artigo abstrai demais: separar “transformar nome de arquivo em bytes” em seu próprio processo é uma “responsabilidade” muito tênue. O redirecionamento (< file cmd) já desacopla a fonte do processamento.
  • Alguns dizem que cat torna os pipelines mais componíveis e mentalmente consistentes; críticos respondem que a modularidade não melhora em comparação com o uso de argumentos de arquivo embutidos ou redirecionamentos.

Sintaxe de shell, redirecionamento e legibilidade

  • Grande parte da discussão gira em torno de cat file | cmd vs <file cmd vs cmd <file.
  • Vários apontam que shells POSIX permitem que redirecionamentos apareçam em qualquer parte do comando simples, por exemplo <access.log head -n 500 | grep mail | perl ....
  • As opiniões divergem sobre legibilidade: alguns acham <file cmd elegante e simétrico (<infile cmd >outfile), outros o consideram visualmente feio e mais difícil de o olho escanear do que cat infile | cmd.
  • Há debate sobre se redirecionamento é conceitualmente uma “etapa do pipeline” ou mera sintaxe de shell.

Desempenho, correção e preocupações com scripts

  • Um grupo diz que “useless cat” é principalmente pedagógico: ele revela incompreensão e adiciona um processo e uma cópia de dados desnecessários, o que pode importar em scripts, arquivos grandes ou em plataformas lentas.
  • Contraponto: para a maioria das cargas reais, a sobrecarga de fork/pipe é irrelevante; correção e legibilidade importam mais, e os avisos de UUoC do shellcheck podem ser mais incômodos do que úteis.
  • Alguns observam que passar um nome de arquivo permite que programas inspecionem o descritor de arquivo (detecção de TTY, buffering, cor, etc.), algo que um pipe com cat pode obscurecer. Outros veem esses casos como nichados.

Fluxos interativos e ergonomia

  • Muitos justificam cat como uma conveniência interativa: começam com cat file, depois pressionam a seta para cima e adicionam | grep ..., | head ..., etc., refinando filtros iterativamente.
  • Aparecem sugestões para usar o histórico mais rapidamente: !$, $_, Alt+. e outros truques do readline/vi-mode, além de recursos do zsh como $READNULLCMD e substituição de processo.
  • Alguns preferem sempre começar com <input X | Y | Z >output, para que o redirecionamento de entrada permaneça estável enquanto etapas são adicionadas ou removidas.

Ferramentas alternativas e recursos menos conhecidos

  • Menções a tac, rev, nl, zgrep, lesspipe, xargs, awk, perl, sed e comparação com substituição de processo (diff -aui <(xxd a) <(xxd b)).
  • cat -A, cat -n, here-docs, usar cat como transformação identidade em funções, como um editor simples (cat > file) ou como injetor de template (cat - dentro de heredocs) são destacados como usos realmente “úteis” de cat.

Humor e tangentes

  • Surgem inúmeras piadas com o gato (animal), referências a livros e trocadilhos de física/álgebra linear, além de comentários meta sobre o preciosismo do HN e a dinâmica social da “polícia do UUoC”.