JC convierte la salida de herramientas populares de línea de comandos a JSON

Artículo original ↗ Discusión en Hacker News ↗

Muchos desarrolladores quieren que las herramientas tradicionales de línea de comandos de Unix emitan datos estructurados como JSON en lugar de texto improvisado, lo que haría mucho más fácil la automatización y el análisis de registros. El proyecto `jc` aborda esto convirtiendo la salida de docenas de comandos existentes en JSON, lo que recibe elogios como una solución puente práctica, pero también genera preocupación por el mantenimiento a largo plazo a medida que evolucionan las herramientas y los formatos. Los participantes comparan este enfoque con alternativas como los pipelines de objetos de PowerShell, libxo de FreeBSD, journald y shells más nuevos como Nushell, y varios argumentan que el soporte nativo de `--json` en las utilidades principales debería acabar reemplazando a los analizadores externos.

Reacción general a jc

  • A muchos les parece muy atractiva la idea: una forma genérica de convertir la salida clásica de la CLI en JSON para usarla con herramientas como jq, Nushell o PowerShell.
  • Se ve como un puente pragmático hasta que más herramientas admitan de forma nativa salida --json (o similar).
  • Algunos usuarios ya lo combinan con otros shells estructurados (por ejemplo, Nushell, PowerShell) y les gusta la ergonomía.

Deseo de salida estructurada en la CLI

  • Fuerte apoyo para una bandera estándar de salida JSON (o JSONL / NDJSON) en las herramientas Unix (por ejemplo, --json, -j).
  • Comparaciones con:
    • El pipeline de PowerShell de “todo es un objeto”.
    • libxo de FreeBSD y el enfoque de SerenityOS de JSON en /proc.
    • journalctl -o json de journald.
  • Varios ejemplos de herramientas ya compatibles con JSON: ip, kubectl -o json, lsblk --json, TShark, AWS CLI (en su mayoría), herramientas de FreeBSD mediante libxo.

Preocupaciones sobre el análisis y el mantenimiento

  • Escepticismo sobre la mantenibilidad a largo plazo:
    • Los formatos de salida varían según la versión, las banderas y el entorno.
    • Riesgo de que las suposiciones en los analizadores fallen con las actualizaciones.
  • Contrapuntos:
    • Las herramientas Unix principales y muchos formatos de archivo son estables y rara vez cambian.
    • jc admite plugins, descargando parte del mantenimiento en la comunidad.
    • El autor informa de relativamente pocas roturas; la mayoría de los problemas son casos límite menores.

Alternativas y enfoques relacionados

  • Algunos sostienen que las herramientas upstream deberían implementar directamente salida estructurada en lugar de depender de envoltorios.
  • Otros prefieren centralizar la lógica de análisis en una herramienta dedicada (jc, libxo, TXR, textfsm) para evitar regex/awk improvisados por todas partes.
  • Nushell se destaca como una alternativa que trata los resultados de los comandos como datos estructurados por diseño.
  • PowerShell es elogiado por sus pipelines de objetos, pero criticado por ser complejo e inconsistente, y por estar estrechamente acoplado a .NET.

Debate sobre LLM y análisis

  • Un sector propone usar LLM para analizar texto arbitrario o incluso para generar analizadores, enfatizando un menor costo de desarrollo.
  • Otro sector rechaza eso con fuerza:
    • Excesivo, ineficiente, difícil de verificar y propenso a errores no deterministas.
    • Los analizadores escritos a mano o basados en reglas simples se consideran más fiables para este dominio.

Reflexiones más amplias sobre la filosofía Unix

  • La discusión aborda:
    • Las limitaciones de los pipelines Unix de “solo texto”.
    • El deseo de tipos de datos más ricos (números, fechas) y de mejores esquemas/versionado.
    • La tensión entre “mantener las herramientas simples” y “interfaces estructuradas modernas”.