Shellcheck encontra bugs nos seus scripts de shell

Artigo original ↗ Discussão no Hacker News ↗

ShellCheck, uma ferramenta de análise estática para scripts de shell, é elogiada por revelar rapidamente bugs sutis e padrões perigosos em tudo, desde scripts legados de manutenção até pipelines modernos de CI. Comentadores descrevem sua integração em hooks de pre-commit e wrappers para GitLab CI, ao mesmo tempo em que apontam ferramentas complementares como linters de Dockerfile e servidores de linguagem para bash. Ao mesmo tempo, muitos argumentam que automação complexa deveria sair do shell por completo e ir para linguagens como Python, Haskell ou Swift, usando shell apenas como uma cola fina em torno de ferramentas de linha de comando e contando com linters para manter até esse uso restrito seguro.

Sentimento geral sobre ShellCheck

  • Amplamente elogiado como uma ferramenta “essencial”; detecta bugs sutis até mesmo para usuários de shell muito experientes.
  • Especialmente valorizado em bases grandes ou legadas de scripts de shell e em pipelines de CI.
  • Alguns consideram-no essencial a ponto de impor “nenhum script executa se o ShellCheck falhar”, por meio de wrappers ou shebangs estritos.

Integração em CI / Fluxo de trabalho de desenvolvimento

  • Padrão comum: executar ShellCheck via hooks de pre-commit e jobs de CI.
  • Ponto problemático: shell embutido em outros arquivos (por exemplo, YAML do GitLab CI, GitHub Actions, Dockerfiles, Justfiles) é mais difícil de analisar; vários usuários criaram wrappers ou hooks para extrair e fazer lint dessas seções.
  • Alguns defendem colocar todo shell não trivial em scripts separados chamados pela CI, tanto para lint quanto para portabilidade.
  • Alternativas como Dagger buscam codificar pipelines de CI/CD em linguagens de programação reais; há debate sobre maturidade e detalhes de integração com GitLab.

Shell vs Outras Linguagens

  • Forte discordância:
    • Um grupo: evitar shell sempre que possível; usar Python, Ruby, Go, Haskell, Swift, etc., especialmente para lógica complexa ou código sensível à segurança.
    • Outro grupo: shell é ideal para pequenos scripts de “cola” e tarefas de CI; não há maneira mais simples de compor ferramentas de CLI.
  • Python é frequentemente proposto como a principal alternativa, mas as pessoas reclamam de empacotamento, distribuição e sobrecarga de runtime.
  • Alguns relatam migrações bem-sucedidas de Bash para Haskell (Turtle/Shh) ou Swift (Shwift), ganhando segurança de tipos e estrutura.

Limitações e Casos de borda

  • ShellCheck tem dificuldades com:
    • source/imports entre múltiplos arquivos.
    • Zsh (suporte removido; forçar --shell=bash só funciona parcialmente).
    • Alguns problemas de segurança, por exemplo, injeção por expansão aritmética, a menos que seja configurado de forma mais rígida.
    • Particularidades de versões do Bash (set -u, arrays vazios, arrays associativos, comportamento de [[ -v ... ]] diferem entre versões).
  • Usuários frequentemente personalizam regras (por exemplo, desativando verificações de estilo para ${var} ou exigência obrigatória de aspas).

Boas práticas de shell discutidas

  • Recomendações frequentes: set -u, -e, -o pipefail, -n para dry-run, e uso liberal de trap para limpeza.
  • Debate sobre colocar opções no shebang vs set (portabilidade e preocupações com o estilo de invocação).
  • Alguns promovem um wrapper de “modo estrito” ou ferramentas de autocorreção como shellharden para impor scripts mais seguros e consistentes.