JC converts the output of popular command-line tools to JSON

Original Article ↗ Hacker News Discussion ↗

Many developers want traditional Unix command-line tools to emit structured data like JSON instead of ad‑hoc text, making automation and log parsing far easier. The `jc` project tackles this by converting the output of dozens of existing commands into JSON, drawing praise as a practical bridge solution but also concern over long‑term maintenance as tools and formats evolve. Participants contrast this approach with alternatives such as PowerShell’s object pipelines, FreeBSD’s libxo, journald, and newer shells like Nushell, and several argue that native `--json` support in core utilities should ultimately replace external parsers.

Overall Reaction to jc

  • Many find the idea very appealing: a generic way to turn classic CLI output into JSON for use with tools like jq, Nushell, or PowerShell.
  • Seen as a pragmatic bridge until more tools natively support --json (or similar) output.
  • Some users already pair it with other structured shells (e.g., Nushell, PowerShell) and like the ergonomics.

Desire for Structured CLI Output

  • Strong support for a standard JSON (or JSONL / NDJSON) output flag across Unix tools (e.g., --json, -j).
  • Comparisons to:
    • PowerShell’s “everything is an object” pipeline.
    • FreeBSD’s libxo and SerenityOS’s JSON-in-/proc approach.
    • Journald’s journalctl -o json.
  • Several examples of existing JSON-capable tools: ip, kubectl -o json, lsblk --json, TShark, AWS CLI (mostly), FreeBSD tools via libxo.

Concerns About Parsing & Maintenance

  • Skepticism about long-term maintainability:
    • Output formats vary by version, flags, and environment.
    • Risk that assumptions in parsers will break on updates.
  • Counterpoints:
    • Core Unix tools and many file formats are stable and rarely change.
    • jc supports plugins, offloading some maintenance to the community.
    • Author reports relatively few breakages; most issues are minor edge cases.

Alternatives & Related Approaches

  • Some argue upstream tools should implement structured output directly instead of relying on wrappers.
  • Others like centralizing parsing logic in a dedicated tool (jc, libxo, TXR, textfsm) to avoid ad‑hoc regex/awk everywhere.
  • Nushell is highlighted as an alternative that treats command results as structured data by design.
  • PowerShell is praised for object pipelines but criticized as complex and inconsistent, and tightly coupled to .NET.

LLMs and Parsing Debate

  • One camp suggests using LLMs to parse arbitrary text or even to generate parsers, emphasizing lower dev cost.
  • Another camp strongly pushes back:
    • Overkill, inefficient, hard to verify, and prone to nondeterministic errors.
    • Handwritten or simple rule-based parsers are seen as more reliable for this domain.

Broader Unix Philosophy Reflections

  • Discussion touches on:
    • Limitations of “text-only” Unix pipelines.
    • Desire for richer data types (numbers, dates) and better schemas/versioning.
    • Tension between “keep tools simple” and “modern structured interfaces.”