6 ms·

JSON is not immediately usable by and is cumbersome to parse correctly in a shell. A simple line-based shell variable name=value format works unreasonably well

JSON is not immediately usable by and is cumbersome to parse correctly in a shell. A simple line-based shell variable name=value format works unreasonably well. For example: # ls --shell-var ./thefile dir="/home/user" file="thefile" size=1234 ... # eval $(ls --shell-var ./thefile); echo $size 1234 If this had been in shells and cmdline tools since the beginning it would have saved so much work, and the security problems could have been dealt with by an eval that only set variables, adding a prefix/scope to variables, and so on. Unfortunately it's too late for this and today you'll be using a pipeline to make the json output shell friendly or use some substring hacks that probably work most of the time.

simonw 2y ago
I use jq - which ChatGPT knows inside out, so I can generally get exactly what I want from it with a single prompt.
kitd 2y ago
That's not your original request though, to use line-based data. It seems you're determined not to use jq but if anything, json output | jq is more the unix way than piping everything through shell vars.
- mlhpdx 2y ago
  And, the author isn’t suggesting only having JSON output, but adding it as an option for those of use that would make use of it. The plain text should remain as well (and has to or many, many things would break). On a separate point, I find the JSON much easier to reason about. The wall of text output doesn’t work for my brain - I just can’t see it all. Structuring/nesting with clear delineations makes it far easier for me to grok.
- bsdetector 2y ago
  > That's not your original request though, to use line-based data. It wasn't my request and OP (not me) said "line-based data" is best. The comment I replied to said "Newline-delimited JSON ... a line-based format". If the only objection you have is "but that's line-based!" then you're in a completely different conversation. > if anything, json output | jq is more the unix way than piping everything through shell vars. The unix way is line-based. The comment I replied to is talking about line-based output. Line-based output is the only structure for data universal to unix cmdline tools - even tab/space isn't universal; sending structured non-line-delimited data to a program to unpack it is the least unix-like way to do it. Also there's no pipe in the shell-variable output scheme I described, whereas "json | jq" is a shell pipeline.
starttoaster 2y ago
That's great for key=value data, but more complex data structures don't work so well in that format, JSON does. "Why would you need to represent data as a complex data structure?" Sometimes attributes are owned by a specific entity, and that entity might own multiple attributes. It might even own other sub-entities. JSON represents that. Key=value does not.
- bsdetector 2y ago
  JSON is literally key=value, just nested. Which you can do with shell variables. The question was "What's not to like [about JSON output from cmdline tools]?" and the answer is that it's cumbersome to read in a shell and all but requires another pipeline stage. I didn't even recommend shell variable output and made it clear this isn't today a reasonable solution so I'm not sure where this hostility in the replies comes from, but I assume from recognition that it's a more practical solution to reading data within a shell but not wanting that to be so.
  - starttoaster 2y ago
    > JSON is literally key=value, just nested. The nature of being nested, and also containing structures like lists, maps, etc. All of which makes it more complicated than key=value. > The question was "What's not to like [about JSON output from cmdline tools]?" and the answer is that it's cumbersome to read in a shell and all but requires another pipeline stage. It depends on the intended use for your shell program. If you intend the CLI tool to be used in CI pipelines (eg. your CLI tool's output is being read by an automated process on a computer) and the data it outputs is more complicated than a simple key=value, JSON is great for that. Your CI program can pipe to jq. You as a human can pipe to jq, though I agree it's somewhat less desirable. Though just piping to jq without any arguments pretty prints it for you which also makes it fairly readable for humans. > so I'm not sure where this hostility in the replies comes from You're reading into hostility where there isn't any.
    - bsdetector 2y ago
      > The nature of being nested, and also containing structures like lists, maps, etc. All of which makes it more complicated than key=value. These are javascript objects, which are key-value. A list array is just keyed by a number instead of a string. They're functionally exactly the same as name=value except JSON is parsed depth-first whereas shell variables are breadth-first parsing (which is way better from shells). Do you have an example of a CLI tool - intended for human use - that has output so complicated it can't be easily mapped to name=value? I don't think there is one, and it's certainly not common. > You're reading into hostility where there isn't any. I think "it seems you're determined not to use jq" is pretty hostile since I made no intimation of that at all.

simonw 2y ago

I use jq - which ChatGPT knows inside out, so I can generally get exactly what I want from it with a single prompt.

kitd 2y ago

That's not your original request though, to use line-based data. It seems you're determined not to use jq but if anything, json output | jq is more the unix way than piping everything through shell vars.

mlhpdx 2y ago
And, the author isn’t suggesting only having JSON output, but adding it as an option for those of use that would make use of it. The plain text should remain as well (and has to or many, many things would break). On a separate point, I find the JSON much easier to reason about. The wall of text output doesn’t work for my brain - I just can’t see it all. Structuring/nesting with clear delineations makes it far easier for me to grok.
bsdetector 2y ago
> That's not your original request though, to use line-based data. It wasn't my request and OP (not me) said "line-based data" is best. The comment I replied to said "Newline-delimited JSON ... a line-based format". If the only objection you have is "but that's line-based!" then you're in a completely different conversation. > if anything, json output | jq is more the unix way than piping everything through shell vars. The unix way is line-based. The comment I replied to is talking about line-based output. Line-based output is the only structure for data universal to unix cmdline tools - even tab/space isn't universal; sending structured non-line-delimited data to a program to unpack it is the least unix-like way to do it. Also there's no pipe in the shell-variable output scheme I described, whereas "json | jq" is a shell pipeline.

starttoaster 2y ago

That's great for key=value data, but more complex data structures don't work so well in that format, JSON does. "Why would you need to represent data as a complex data structure?" Sometimes attributes are owned by a specific entity, and that entity might own multiple attributes. It might even own other sub-entities. JSON represents that. Key=value does not.

bsdetector 2y ago
JSON is literally key=value, just nested. Which you can do with shell variables. The question was "What's not to like [about JSON output from cmdline tools]?" and the answer is that it's cumbersome to read in a shell and all but requires another pipeline stage. I didn't even recommend shell variable output and made it clear this isn't today a reasonable solution so I'm not sure where this hostility in the replies comes from, but I assume from recognition that it's a more practical solution to reading data within a shell but not wanting that to be so.
- starttoaster 2y ago
  > JSON is literally key=value, just nested. The nature of being nested, and also containing structures like lists, maps, etc. All of which makes it more complicated than key=value. > The question was "What's not to like [about JSON output from cmdline tools]?" and the answer is that it's cumbersome to read in a shell and all but requires another pipeline stage. It depends on the intended use for your shell program. If you intend the CLI tool to be used in CI pipelines (eg. your CLI tool's output is being read by an automated process on a computer) and the data it outputs is more complicated than a simple key=value, JSON is great for that. Your CI program can pipe to jq. You as a human can pipe to jq, though I agree it's somewhat less desirable. Though just piping to jq without any arguments pretty prints it for you which also makes it fairly readable for humans. > so I'm not sure where this hostility in the replies comes from You're reading into hostility where there isn't any.
  - bsdetector 2y ago
    > The nature of being nested, and also containing structures like lists, maps, etc. All of which makes it more complicated than key=value. These are javascript objects, which are key-value. A list array is just keyed by a number instead of a string. They're functionally exactly the same as name=value except JSON is parsed depth-first whereas shell variables are breadth-first parsing (which is way better from shells). Do you have an example of a CLI tool - intended for human use - that has output so complicated it can't be easily mapped to name=value? I don't think there is one, and it's certainly not common. > You're reading into hostility where there isn't any. I think "it seems you're determined not to use jq" is pretty hostile since I made no intimation of that at all.