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

31–40 of 136 posts

Re: JC – JSONifies the output of many CLI tools

#31

Post by dmoura »

This is great!

I am the author of SPyQL [1]. Combining JC with SPyQL you can easily query the json output and run python commands on top of it from the command-line :-) You can do aggregations and so forth in a much simpler and intuitive way than with jq.

I just wrote a blogpost [2] that illustrates it. It is more focused on CSV, but the commands would be the same if you were working with JSON.

[1] https://github.com/dcmoura/spyql [2] https://danielcmoura.com/blog/2022/spyql-cell-towers/

Re: JC – JSONifies the output of many CLI tools

#33

Post by drunkpotato »

visarga wrote: post #6

love it, json could be the best way to pipe data between processes because it is text, but structured

So is xml. Json is relatively unstructured compared to other formats.

I think json has several advantages though. It’s a relatively lightweight and widely known serialization standard, rich enough for most cases and extensible in others, and it has easy to use parsers in all major programming languages.

Also jsonlines is a simple addition that make it easy for json to play well with non-json aware older Unix tools.

It has a few shortcomings but I think its advantages outweigh them, and it’s become a pretty widely used standard in a short time.

Re: JC – JSONifies the output of many CLI tools

#34

Post by brodo »

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…

Nushell has this too. I‘ve tried is as daily driver for a while. It‘s not there yet, but almost. After it hits 1.0 I‘m going to switch for good and leave the duck tape solutions behind.

Re: JC – JSONifies the output of many CLI tools

#36

Post by berkes »

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

Is "redundancy" that you have to provide --dig?

I can imagine `jc` having some detection built in, from which it determines the command/content it's being parsed. Doesn't seem to have it, yet, and I'm generally no big fan of "magic" like this, but it would remove the redundancy.

Having it as a pipe, allows for much more, though.

   some_expensive_command > out.log
   jc --expensive-cmd
Or

   hourly_dig.sh > example_com_records_$(date +%F+%s)
   cat example_com_records_* | jc --dig

Re: JC – JSONifies the output of many CLI tools

#38

Post by tgv »

drunkpotato wrote: post #33
visarga wrote: post #6

love it, json could be the best way to pipe data between processes because it is text, but structured

So is xml. Json is relatively unstructured compared to other formats. I think json has several advantages though. It’s a relatively lightweight and widely known serialization standard, rich enough for most cases and extensible in others, and it has easy to use parsers in all major programming languages. Also jsonlines is a simple addition that make it easy for json to play well with non-json aware older Unix tools. I…

I just learned about gron (elsewhere in the comment section: https://news.ycombinator.com/item?id=33448471). That overcomes some of jsonlines problems.

Re: JC – JSONifies the output of many CLI tools

#40

Post by berkes »

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 outside of gnutools, is then reserved for my aliases. If jsonquery is too long to type, AND I lack autocomplete, then an alias is easy and fast to make. alias jq=jsonquery.

In the case of this tool, it will conflict with a specialised alias I have: `alias jc=javac -Werror`. Easy to solve by me with another alias, but a practical example of why I dislike tools "squatting" the two letter namespace.

Post reply on HN