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

21–30 of 136 posts

Re: JC – JSONifies the output of many CLI tools

#21

Post by jerjerjer »

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…

> Powershell has this, but it's a binary format

Well, yes - powershell passes binary objects but as you can always:

1) access their properties 2) pass them downstream 3) serialize to json/csv 4) instantiate from json/csv

I think this is both human- and machine-readable enough (even through internal format is binary, but working with Powershell you are never really exposed to it).

How do you think it can be improved?

In my opinion object io IS the best part of powershell - it allows us to ditch results wrangling with sed/awk/grep entirely. I'm super interested if there's an even better way forward.

Re: JC – JSONifies the output of many CLI tools

#23

Post by chii »

mg wrote: post #22

dig example.com | jc --dig Seems a bit redundant. Maybe it should be the other way round? jc dig example.com Similar to how you do time dig example.com

`time` needs to be the one to exec the command because they need to know when the command they are timing starts. Therefore, `time` cannot use pipes, as by then, the command being timed would've already started!

`jc` doesn't need to know anything about the command producing the output - just the format of the output. So using a pipe and stdin makes a lot of sense.

Re: JC – JSONifies the output of many CLI tools

#24

Post by DougBTX »

mg wrote: post #22

dig example.com | jc --dig Seems a bit redundant. Maybe it should be the other way round? jc dig example.com Similar to how you do time dig example.com

Yes, that works, there are examples on the page like:

    $ jc dig example.com | jq -r '.[].answer[].data'
    93.184.216.34
It uses the first argument to infer the command output type.

Re: JC – JSONifies the output of many CLI tools

#27

Post by pastage »

I Love using this in streams of data, but there is a lot to be said about the pit falls. Some of them; first you might want to filter with grep first and that leads to missing metadata, second error handling is a good thing but people tend to ignore errors and then not handle them. This is basically what filebeat/logstash from Elastic does, which is a beast at parsing (and impossible to use from command line).

The power of plain text pipes is that you do not interpret them and that makes them fast, that is usefull because you handle both 100 bytes, 1MB and 1TB as input. You choose what you parse keeping it simple, fast and usually error free. This tool miss the, fast, simple and human readable part of debugging pipes. Which is fine!

Re: JC – JSONifies the output of many CLI tools

#28

Post by zikduruqe »

asicsp wrote: post #13
enriquto wrote: post #3

In the opposite direction, if you want to recover a human-editable text stream from json data, you run gron.

Link: https://github.com/tomnomnom/gron Discussion: https://news.ycombinator.com/item?id=25006277 366 points | Nov 6, 2020 | 91 comments

Came looking for gron recommendations.

Re: JC – JSONifies the output of many CLI tools

#29

Post by vbezhenar »

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.
Post reply on HN