JC converte a saída de ferramentas populares de linha de comando para JSON

Artigo original ↗ Discussão no Hacker News ↗

Muitos desenvolvedores querem que ferramentas tradicionais de linha de comando Unix emitam dados estruturados como JSON em vez de texto ad hoc, tornando automação e parsing de logs muito mais fáceis. O projeto `jc` enfrenta isso convertendo a saída de dezenas de comandos existentes em JSON, sendo elogiado como uma solução de ponte prática, mas também recebendo preocupações sobre manutenção de longo prazo à medida que ferramentas e formatos evoluem. Os participantes contrastam essa abordagem com alternativas como os pipelines de objetos do PowerShell, o libxo do FreeBSD, o journald e shells mais novos como o Nushell, e vários defendem que o suporte nativo a `--json` em utilitários centrais deveria acabar substituindo parsers externos.

Reação geral ao jc

  • Muitos acham a ideia muito atraente: uma forma genérica de transformar a saída clássica de CLI em JSON para uso com ferramentas como jq, Nushell ou PowerShell.
  • Visto como uma ponte pragmática até que mais ferramentas passem a oferecer suporte nativo a saída --json (ou مشابه).
  • Alguns usuários já o combinam com outros shells estruturados (por exemplo, Nushell, PowerShell) e gostam da ergonomia.

Desejo por saída estruturada em CLI

  • Forte apoio a uma flag padrão de saída JSON (ou JSONL / NDJSON) em ferramentas Unix (por exemplo, --json, -j).
  • Comparações com:
    • O pipeline do PowerShell, em que “tudo é um objeto”.
    • O libxo do FreeBSD e a abordagem JSON em /proc do SerenityOS.
    • journalctl -o json do journald.
  • Vários exemplos de ferramentas já compatíveis com JSON: ip, kubectl -o json, lsblk --json, TShark, AWS CLI (em sua maior parte), ferramentas do FreeBSD via libxo.

Preocupações com parsing e manutenção

  • Ceticismo quanto à manutenção a longo prazo:
    • Formatos de saída variam por versão, flags e ambiente.
    • Risco de que suposições nos parsers quebrem com atualizações.
  • Contra-argumentos:
    • Ferramentas Unix centrais e muitos formatos de arquivo são estáveis e raramente mudam.
    • jc oferece plugins, transferindo parte da manutenção para a comunidade.
    • O autor relata relativamente poucas quebras; a maioria dos problemas são casos extremos menores.

Alternativas e abordagens relacionadas

  • Alguns argumentam que as ferramentas upstream deveriam implementar saída estruturada diretamente, em vez de depender de wrappers.
  • Outros gostam de centralizar a lógica de parsing em uma ferramenta dedicada (jc, libxo, TXR, textfsm) para evitar regex/awk improvisados em todo lugar.
  • Nushell é destacado como uma alternativa que trata os resultados de comandos como dados estruturados por design.
  • PowerShell é elogiado pelos pipelines de objetos, mas criticado por ser complexo e inconsistente, além de fortemente acoplado ao .NET.

LLMs e o debate sobre parsing

  • Um grupo sugere usar LLMs para analisar texto arbitrário ou até gerar parsers, enfatizando menor custo de desenvolvimento.
  • Outro grupo reage fortemente contra:
    • Exagero, ineficiente, difícil de verificar e sujeito a erros não determinísticos.
    • Parsers escritos manualmente ou baseados em regras simples são vistos como mais confiáveis para esse domínio.

Reflexões mais amplas sobre a filosofia Unix

  • A discussão aborda:
    • Limitações dos pipelines Unix “apenas texto”.
    • Desejo por tipos de dados mais ricos (números, datas) e melhores schemas/versionamento.
    • Tensão entre “manter as ferramentas simples” e “interfaces estruturadas modernas”.