5 ms·

./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

• alerighi 2y ago
  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.
• mlhpdx 2y ago
  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.
• dylan604 2y ago
  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
  • Jcowell 2y ago
    Orient the idea be that because it’s json there’s a schema somewhere the end user can refer to?
    • dylan604 2y ago
      as if the output of the other command also isn't available?
      • zulu-inuoe 2y ago
        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
        • dylan604 2y ago
          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.
• hgs3 2y ago
  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 https://en.wikipedia.org/wiki/Comma-separated_values
  • photonthug 2y ago
    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
  • kortex 2y ago
    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
  • zulu-inuoe 2y ago
    One of my values contains a literal ,