Um dois-pontos no shell não faz nada. Use-o mesmo assim

Artigo original ↗ Discussão no Hacker News ↗

Um post de blog sobre o comando `:` do shell POSIX, que não faz nada, gera debate sobre se esses idioms concisos são ferramentas poderosas e elegantes ou armadilhas para a legibilidade. Comentadores destacam usos práticos de `:` para validação de argumentos, redirecionamento e truques de script, mas muitos argumentam que comprimir lógica de várias linhas em one-liners opacos torna os scripts de shell mais difíceis de manter, especialmente em escala. A troca se amplia para uma crítica ao próprio scripting em shell — suas armadilhas, peculiaridades de portabilidade e papel na era do Python, PowerShell e código gerado por LLMs.

Utilidade do comando : (null)

  • Muitos consideram alguns idioms genuinamente úteis, especialmente para:
    • Validar argumentos/variáveis de ambiente obrigatórios: ${1:?argumento ausente} ou VAR="${VAR:?mensagem}".
    • Fornecer valores padrão: : "${DOTFILES_PATH:=$HOME/.dotfiles}".
    • Agir como um espaço reservado em if/while quando um comando é sintaticamente necessário.
    • Servir como uma linha de “docstring” dentro de funções ou como um alias fictício para facilitar a descoberta.
  • Outros veem a maioria dos exemplos como espertos, porém impráticos, basicamente apenas comprimindo código legível em one-liners.

Detalhes sobre redirecionamento, truncamento e portabilidade

  • Alguns apontam que : >file tanto trunca quanto cria o arquivo, o que supostamente é subestimado no artigo.
  • A discussão esclarece que redirecionamentos podem funcionar sem :, mas o comportamento difere entre shells (por exemplo, o zsh imprimirá o conteúdo do arquivo para < file a menos que esteja anexado a :).
  • Exemplos com subshell e sem subshell mostram comportamentos diferentes sob set -e / --posix, justificando ( : < file ) em alguns contextos.
  • : é builtin, enquanto true pode ser um utilitário externo; : ignora argumentos com segurança, então às vezes é preferido.

Legibilidade vs. esperteza

  • Forte resistência a transformar código de várias linhas e compreensível em one-liners densos.
  • Vários argumentam que qualquer coisa além de scripts pequenos deve priorizar clareza e tratamento explícito de erros, não concisão.
  • Alguns veem esses truques como quebra-cabeças divertidos, adequados para uso pessoal ou código em modo golf, mas inaceitáveis em produção.

Shell vs. outras linguagens (e LLMs)

  • Diversos comentários argumentam que a sintaxe do POSIX shell é fundamentalmente ruim para programas maiores; Python/Ruby/PowerShell são preferidos para scripts mantíveis.
  • Outros defendem que o shell é singularmente adequado para pequenas automações e orquestração de processos, apesar de suas idiossincrasias, especialmente quando auxiliado por ferramentas como ShellCheck.
  • Relata-se que LLMs são bons em gerar scripts complexos em shell/Perl, mas ainda exigem revisão; qualidade e excesso de engenharia são reclamações recorrentes.

Shells e ecossistemas alternativos

  • Menções a fish, nushell, oil, zsh e, especialmente, PowerShell como opções mais modernas ou expressivas, com debate sobre:
    • Tempo de inicialização e tamanho da dependência.
    • Adequação como “shell do sistema” versus linguagem de script.
    • Verbosidade, complexidade e disponibilidade multiplataforma.