Hacker News Reader

Comment by tyingq | Hacker News Reader

Makes me wonder if there might ever be support for standardizing a json input/output schema for all the typical Linux userland stuff, /proc structures, and so on. Then a "jq" like utility would have more value. Having it co-exist with the current "just a bunch of text" isn't ideal though, as you'd be stuck with something clunky like adding a switch to every command. Or an environment variable that changes everything. Or a "j-" version of each.

View on HN

The best approach I've heard is to "standardize" on doing it with IO descriptors, so we'd have stdin, stdout, stderr, stdjsin, stdjsout. Individual programs could check which file descriptors are open and read/write the format automatically. This may also be the best way to leverage the benefits of plain text and structured data and move between them quite naturally as the situation demands. It's also really not that hard to write a few basic utils or fork old ones to the new scheme as a proof of concept, but AFAIK no one ever has.

While we're here I'd also like to see more experimentation on using file desciprtors with GUI/TUI tools. I've had good like using things like vim in the middle of a pipe for data that needs a human touch before being passed through. The suckless world uses dmenu quite a bit.

A piped array of "octets" (C style character bytes, like void*) of nil or more length is probably the most basic interface possible for relevant hardware.

A structured interface introduces much more complexity. Rather than standardize on any specific 'wire' format a better approach might be to have a bi-directional connection and a standard for negotiating across it.

This might allow different forms of communication (E.G. a shared ringbuffer), negotiation of protocols, signaling when ready / blocked / needing more to proceed, what format(s) to use and if multiple streams should be used (as well as how to multiplex them)... etc. Programs might even be added to the middle to setup the preferences between two applications and then tell the OS that they're done and to just connect the input and output directly.

JFTR, stumbled over this recently: https://github.com/kellyjonbrazil/jc "CLI tool and python library that converts the output of popular command-line tools and file-types to JSON or Dictionaries. This allows piping of output to tools like jq and simplifying automation scripts."

There was an endeavor sometime around 1998-2002 to reimplement a lot of coreutils, textutils, and other GNU-ish *utils in perl with regular, structured output formats (I believe XML at the time). Unfortunately, I don't remember the exact name and I don't think it was ever completed enough to be a contender.

libxo on FreeBSD tries to do this to some extent but a way to turn json back into neat tables is somehow missing (jq isn't great in that regard).

Ah, that's interesting, thanks for sharing. Their github README does a nice job of showing how it doesn't add a lot of work: https://github.com/Juniper/libxo

Shameless plug - I created a cli tool called jtbl[0] that converts json output to tables in the terminal.

[0] https://github.com/kellyjonbrazil/jtbl

I know there's a project started a few years ago, building something like this for bash called Relational pipes[1].

It's perennially in my "to check out" list and I haven't actually played around with it, mainly because I'm lazy and it's not in AUR.

So can't comment how ready it is to use to today. But it looks interesting.

[1] https://relational-pipes.globalcode.info/v_0/index.xhtml

Maybe a better idea would be something like the HTTP Accept header for the shell, where the user can set it once and any supporting application will respond in that format.

Reply on news.ycombinator.com