Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

JC – JSONifies the output of many CLI tools

kellyjonbrazil.github.io

Post reply on HN
Print view View original

61–70 of 136 posts

Re: JC – JSONifies the output of many CLI tools

#61

Post by Sharparam »

artemisart wrote: post #44
berkes wrote: post #40

A slightly related pet-peeve: I don't like it when "random" commands "squat" the two-letter domain, or worse, the one-letter domain: t, jq, jc etc. In my perfect world (which, obviously doesn't exist), commands from tools "in the wild" are at least three letters long. With historical exceptions for gnutools: preferably they'd take the three-letter space, but two-letters (cd, ls, rm etc) is fine. Two letter space outs…

I don't believe it's really an issue in practice, your `jc` alias will just take the priority and you can easily add one for jsonquery -> `path/to/bin/jc`. I think good short command names can help adoption (like for ripgrep, fd) but it's true that we should have a race to squat all the 2 letter names.

Instead of typing the whole path, you can also use `command` or a backslash to bypass aliases

E.g.:

    alias jsonquery='command jq'

Re: JC – JSONifies the output of many CLI tools

#62

Post by ycombobreaker »

artemisart wrote: post #44
berkes wrote: post #40

A slightly related pet-peeve: I don't like it when "random" commands "squat" the two-letter domain, or worse, the one-letter domain: t, jq, jc etc. In my perfect world (which, obviously doesn't exist), commands from tools "in the wild" are at least three letters long. With historical exceptions for gnutools: preferably they'd take the three-letter space, but two-letters (cd, ls, rm etc) is fine. Two letter space outs…

I don't believe it's really an issue in practice, your `jc` alias will just take the priority and you can easily add one for jsonquery -> `path/to/bin/jc`. I think good short command names can help adoption (like for ripgrep, fd) but it's true that we should have a race to squat all the 2 letter names.

I perceive an element of hubris when a tool claims a two-character name. That is a very small namespace, so the tool is effectively staking a claim on mental or emotional real-estate.

Re: JC – JSONifies the output of many CLI tools

#63

Post by dotancohen »

asicsp wrote: post #11

See also: * "Bringing the Unix philosophy to the 21st century (2019)" ( https://blog.kellybrazil.com/2019/11/26/bringing-the-unix-ph... ) - https://news.ycombinator.com/item?id=28266193 238 points | Aug 22, 2021 | 146 comments * "Tips on adding JSON output to your CLI app" ( https://blog.kellybrazil.com/2021/12/03/tips-on-adding-json-... ) - https://news.ycombinator.com/item?id=29435786 183 points | 11 months ago | 1…

If you're bringing that up, then this is the place to spread the word about my dream of a stdmeta file descriptor.

https://unix.stackexchange.com/questions/197809/propose-addi...

Just like we have stdout and stderr, header lines such as those produced by `ps` should be printed to stdmeta. Curl is the worse offender here, outputing meta lines to stderr instead of stdout. A stdmeta file descriptor would make it clear what is data, what is an error, and what is _describing_ the data.

Re: JC – JSONifies the output of many CLI tools

#64

Post by [deleted] »

berkes wrote: post #40

A slightly related pet-peeve: I don't like it when "random" commands "squat" the two-letter domain, or worse, the one-letter domain: t, jq, jc etc. In my perfect world (which, obviously doesn't exist), commands from tools "in the wild" are at least three letters long. With historical exceptions for gnutools: preferably they'd take the three-letter space, but two-letters (cd, ls, rm etc) is fine. Two letter space outs…

[deleted]

Re: JC – JSONifies the output of many CLI tools

#65

Post by [deleted] »

codedokode wrote: post #47

I think that JSON is a bad choice here. It is obvious that CLI commands should produce machine-readable output because they are often used in scripts, and accept machine-readable input as well. Using arbitrary text output was a mistake because it is difficult to parse, especially when spaces and non-ASCII characters are present. A good choice would be a format that is easily parsed by programs but still readable by t…

[deleted]

Re: JC – JSONifies the output of many CLI tools

#66

Post by onion2k »

codedokode wrote: post #47

I think that JSON is a bad choice here. It is obvious that CLI commands should produce machine-readable output because they are often used in scripts, and accept machine-readable input as well. Using arbitrary text output was a mistake because it is difficult to parse, especially when spaces and non-ASCII characters are present. A good choice would be a format that is easily parsed by programs but still readable by t…

If you use something other than JSON you'd have to wait until every app you want to use chooses to update to support your preferred format. That might take a while. Wouldn't it be better to use JSON for the output as that's an acceptable input to lots and lots of applications already, and if you want to read the output just pass it to an app that converts from JSON to "something formatted with pipes, quotes and spaces".

Re: JC – JSONifies the output of many CLI tools

#67

Post by teddyh »

vbezhenar wrote: post #29
spinningslate wrote: post #10

Didn't know about this, the HN dividend pays out again! When wrestling with sed/awk in trying to parse results of a shell command, I've often thought that a shell-standard, structured outpout would be very handy. Powershell[0] has this, but it's a binary format - so not human-readable. I want something in the middle: human- and machine-readable. Without either having to do parsing gymnastics. jc isn't quite that shel…

Shell would benefit from Content-Type/Accept headers. Like you can specify that cat accepts text and jq accepts Json. Then `ip a` would output corresponding type automatically.

“ip” has the -json option; i.e. “ip -json a” gives you straight JSON; no need for JC.

Re: JC – JSONifies the output of many CLI tools

#68

Post by ddulaney »

samuell wrote: post #52
ducktective wrote: post #4

Then pipe it into jq [1] to query parameters or build up a formatted string. Or pipe it into rq [2] to convert the format to yaml, toml etc. [1]: https://stedolan.github.io/jq/tutorial/ [2]: https://github.com/dflemstr/rq#format-support-status

I would wish for jq to be a really generic tool for working with structured data on the commandline, but I have a really hard time figuring out how to do e.g. conditional-based editing etc. Can't get my head around that, and don't find any info about it on the net. Seems even something that just supports SQL (upon JSON) would be better in this regard.

What do you mean by conditional-based editing? I've found its language to be pretty concise and readable, especially with the // operator.

Re: JC – JSONifies the output of many CLI tools

#69

Post by khiqxj »

There are at least 3 ways this can create bugs:

  - It has to parse output of commands which may or may not be intended to be parsed and may or may not have a predictable format. The only way to overcome this is if this program becomes one of the Big Four "UN*X command output -> data" converters

  - It casts things to "float/int"

  - Depending on who made this library, the output itself may not be strict / predictable. Perhaps it will output JSON with two different key names in two different scenarios.
And don't forget that any of these issues will still come up even if they are accommodated for, due to versions of programs changing without the author of this tool knowing.

But yeah basic things having intrinsic shortcomings is a given, when you're using UN*X.

From the nested article:

> Had JSON been around when I was born in the 1970’s Ken Thompson and Dennis Ritchie may very well have embraced it as a recommended output format to help programs “do one thing well” in a pipeline.

They had S-expressions and plenty more options. They also could have just made a format as you can tell with thousands of ad-hoc trendy new formats like YAML and TOML being spewed out every recent year now that programmers discovered data structures.

Re: JC – JSONifies the output of many CLI tools

#70

Post by kbrazil »

samuell wrote: post #52
ducktective wrote: post #4

Then pipe it into jq [1] to query parameters or build up a formatted string. Or pipe it into rq [2] to convert the format to yaml, toml etc. [1]: https://stedolan.github.io/jq/tutorial/ [2]: https://github.com/dflemstr/rq#format-support-status

I would wish for jq to be a really generic tool for working with structured data on the commandline, but I have a really hard time figuring out how to do e.g. conditional-based editing etc. Can't get my head around that, and don't find any info about it on the net. Seems even something that just supports SQL (upon JSON) would be better in this regard.

Hi there - I'm the author of `jc`. I also created `jello`[0], which works just like `jq` but uses python syntax. I find `jq` is great for many things but sometimes more complex operations are easier for me to grok in python.

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

Post reply on HN