Hacker News Reader

Comment by pluto_modadic | Hacker News Reader

./some_command | jq '.memory_use'

vs:

okay, run it once with head (assuming we have a --dry option...) ah, that's the column. okay cut -d"," -f0, ah whoops it's starting at 1. ah, damn, there's a weird comma in the name/quote. oh weird, that one's null, ah heck.

schemas are cool. JSON extends and builds on the UNIX idea of having things pipe and plumb well together.

View on HN

But why JSON and not CSV [1]? Most of what the article suggests, like formatting the output as lines and flattening, is how CSV works. CSV is much easier to parse than JSON (use split(",") or the equivalent). A complete record (JSON object) of CSV data can be parsed in a single line, unlike typical JSON. The line-based nature of CSV makes it far more fault tolerant to broken streams/truncation and more in-line with standard Unix conventions.

[1] https://en.wikipedia.org/wiki/Comma-separated_values

Nested objects? JSON holds json fine, with arbitrary depth, retaining ability to print pretty and parse. Not sure how that’s going to work with csv

A) Csv isn't actually a standard, so there's no one universal way of dealing with it (we can get really close).

B) the keys and values are disjointed in csv as separate rows/columns, vs key:value

C) yes flat is better but when you need nested, nested is useful

One of my values contains a literal ,

Plain text is more easy to reason about, because we are used to process text. A good textual output, that is records delimited by spaces, tabs or a delimiter, to me is all it's needed, for most applications.

An object structure it's much more complex to use. For example an output that is a set of records can be easily imported in an Excel sheet, in an SQL database, processed line by line, without issues. Processing JSON is not straight forward, not all programs support JSON.

Finally JSON can't be processed as a stream, meaning that tools like head, tail, etc. doesn't work on JSON, you have to read it all in memory, or use JSON lines, that is not a standard format, that not all parsers support natively, etc.

JSON is good if for integrating the program inside other programs (as a subprocess), so having an option to input/output JSON in a program is useful, but to me it's not as useful for interactive shell usage. I prefer to use UNIX tools such as grep, cut, head, tail, etc.

But as the article points out, the advice to use unbuffered JSON lines for commands that are line oriented is well given. Not doing that can really make life sad.

you still need to know the schema of the JSON which could also use a dry run as well. not really sure how just because it's JSON solves that in your mind

Orient the idea be that because it’s json there’s a schema somewhere the end user can refer to?

as if the output of the other command also isn't available?

But that output is wildly more variant between applications, especially for cases involving escape sequences, whitespace handling, and so on. All of these are specified in JSON

where is this supposed specification for JSON?

I can make whatever I want in a [{},{},{}] and it be valid JSON. If it's the first time you've used my thing, you'll have to somehow look up how the JSON is structured. Whether that's from howtousething.com, man thing, or thing --help, you'll still need to find out what thing does. it doesn't matter if it's your thing or my thing, but some how, thing needs to be able to tell people what to do. there is no universal thing that thing outputs. otherwise, nobody would need yours or my thing, but someone else's thing already does it.

Reply on news.ycombinator.com