4 ms·

Jq is ok, but the language is awfully unintuitive. It's also not very user-friendly. I've been using gojq with better success

howeyc 4y ago
I just use gron then grep for what I'm looking for.
- dtech 4y ago
  Does it do more than just grep? That's awfully limited compared to what jq can do. I personally like jless for just searching and exploring.
  - wwader 4y ago
    gron is great, i have this in my init.jq file for fq (https://github.com/wader/fq https://github.com/wader/fq). Sadly jq lacks a path_to_expr function so a bit harder to do it with that. def gron: ( path(..) as $p | getpath($p) | scalars | "\($p | path_to_expr) = \(tojson)" | println ); Ex: $ fq gron <<< '{"a": [1,2,{"b": 3}]}' .a[0] = 1 .a[1] = 2 .a[2].b = 3 Great for copy/paste into other expressions when poking around.
stevage 4y ago
Yeah, I like the design goals, I just found the solution was worse than the problem it was solving.
secondcoming 4y ago
I'll never be intelligent enough to use jq properly.
xendo 4y ago
I’ve been using ‚gron’ with good results
pfarrell 4y ago
How is gojq different? Cursory look at the README and it seems like it implements the same language. My problem is the infrequency with which I need to use jq means I don't create a good learning feedback loop. The last time I used it though, I was able to walk down a decently complicated structure (indexed val in an array in a key in a hash in an array) and extract the data I wanted only having to google once. Like awk, though, I know there's a world of functionality I'm just not using.
- sitkack 4y ago
  You should checkout gron, it is great at flattening fragments of json. https://github.com/tomnomnom/gron https://github.com/tomnomnom/gron
  - lathiat 4y ago
    I have started using gron to understand the json structure to then write jq. Other times it does the job alone. It’s great.
    - sitkack 4y ago
      You can pipe the output of gron into fzf, it makes it kinda nice for perusing the flattened json.
  - pfarrell 4y ago
    TIL. Thank you! I took a look and will definitely incorporate this in my work. Definitely a good idea.
  - zikduruqe 4y ago
    Anytime jq is mentioned, gron should be mentioned shortly thereafter. It is a wonderful tool.
- lapser 4y ago
  It is indeed a reimplementation of jq in go, and the reason I use it over jq is many, one of which is that it produces more helpful error messages. In fact, I've moved jq to ojq (sometimes I want to check compatibility), and ln -fs gojq jq.
vbezhenar 4y ago
I feel like it's OK if you use it often, but when you need it once a year, I'm spending too much time trying to figure it out. Some collection of typical problems and solutions would help I guess.
- delecti 4y ago
  I use it a bunch to string together web APIs, and you're absolutely right. The longer I go relying on my library of pre-written strings of commands, the harder it is to write a new one. And you're right again with your second point, because that same library makes for great reference material for myself.
- Someone 4y ago
  The manual (https://stedolan.github.io/jq/manual/ https://stedolan.github.io/jq/manual/) somewhat provides that. Quite a few sections have helpful examples, with links to the sandbox at jqplay.org. The IMO not so good parts of that page are - Quite a few section headers don’t make sense to novices - I think the table of contents would be better if it had subheaders, ideally with one-line descriptions of the features (that probably would solve the issue above) - not every section has examples - some examples use fairly advanced features, making them harder to understand then necessary
AndyKluger 4y ago
I see folks have mentioned gron, and I also want to suggest: - jello (PyPI) - yamlpath (PyPI) - dasel
sph 4y ago
jq is not OK for that exact reason. It's like sendmail, dividing the world into people smart yet obtuse enough to sit and learn its idiosyncrasies, and regular people that go mad and claw their eyes out whenever they try. I tried, more than once, but I guess I'm not smart enough.

howeyc 4y ago

I just use gron then grep for what I'm looking for.

dtech 4y ago
Does it do more than just grep? That's awfully limited compared to what jq can do. I personally like jless for just searching and exploring.
- wwader 4y ago
  gron is great, i have this in my init.jq file for fq (https://github.com/wader/fq https://github.com/wader/fq). Sadly jq lacks a path_to_expr function so a bit harder to do it with that. def gron: ( path(..) as $p | getpath($p) | scalars | "\($p | path_to_expr) = \(tojson)" | println ); Ex: $ fq gron <<< '{"a": [1,2,{"b": 3}]}' .a[0] = 1 .a[1] = 2 .a[2].b = 3 Great for copy/paste into other expressions when poking around.

stevage 4y ago

Yeah, I like the design goals, I just found the solution was worse than the problem it was solving.

secondcoming 4y ago

I'll never be intelligent enough to use jq properly.

xendo 4y ago

I’ve been using ‚gron’ with good results

pfarrell 4y ago

How is gojq different? Cursory look at the README and it seems like it implements the same language. My problem is the infrequency with which I need to use jq means I don't create a good learning feedback loop. The last time I used it though, I was able to walk down a decently complicated structure (indexed val in an array in a key in a hash in an array) and extract the data I wanted only having to google once. Like awk, though, I know there's a world of functionality I'm just not using.

sitkack 4y ago
You should checkout gron, it is great at flattening fragments of json. https://github.com/tomnomnom/gron https://github.com/tomnomnom/gron
- lathiat 4y ago
  I have started using gron to understand the json structure to then write jq. Other times it does the job alone. It’s great.
  - sitkack 4y ago
    You can pipe the output of gron into fzf, it makes it kinda nice for perusing the flattened json.
- pfarrell 4y ago
  TIL. Thank you! I took a look and will definitely incorporate this in my work. Definitely a good idea.
- zikduruqe 4y ago
  Anytime jq is mentioned, gron should be mentioned shortly thereafter. It is a wonderful tool.
lapser 4y ago
It is indeed a reimplementation of jq in go, and the reason I use it over jq is many, one of which is that it produces more helpful error messages. In fact, I've moved jq to ojq (sometimes I want to check compatibility), and ln -fs gojq jq.

vbezhenar 4y ago

I feel like it's OK if you use it often, but when you need it once a year, I'm spending too much time trying to figure it out. Some collection of typical problems and solutions would help I guess.

delecti 4y ago
I use it a bunch to string together web APIs, and you're absolutely right. The longer I go relying on my library of pre-written strings of commands, the harder it is to write a new one. And you're right again with your second point, because that same library makes for great reference material for myself.
Someone 4y ago
The manual (https://stedolan.github.io/jq/manual/ https://stedolan.github.io/jq/manual/) somewhat provides that. Quite a few sections have helpful examples, with links to the sandbox at jqplay.org. The IMO not so good parts of that page are - Quite a few section headers don’t make sense to novices - I think the table of contents would be better if it had subheaders, ideally with one-line descriptions of the features (that probably would solve the issue above) - not every section has examples - some examples use fairly advanced features, making them harder to understand then necessary

AndyKluger 4y ago

I see folks have mentioned gron, and I also want to suggest: - jello (PyPI) - yamlpath (PyPI) - dasel

sph 4y ago

jq is not OK for that exact reason. It's like sendmail, dividing the world into people smart yet obtuse enough to sit and learn its idiosyncrasies, and regular people that go mad and claw their eyes out whenever they try. I tried, more than once, but I guess I'm not smart enough.