51–60 of 61 posts
I too can never remember jq syntax when I need to. I usually just end up writing a Python script to extract the part of the JSON I need.
Earlier quoted context omitted.
Gron looks interesting, but I wish there was an option for bash output!
The main benefit (indeed the purpose) of gron is that the output is much easier to manipulate into what you need using basic gnu utils, instead of trying to shoehorn it into jq's syntax.
You can `grep` through it, yes. But since the output is still structured to be Javascript (which makes it nice in some more immediate ways if you're working interactively) makes it tricky to deal with with e.g. `awk` -- you'd still have to parse the JS line and implement string unescaping, which still makes it more complicated than necessary. And if you work e.g. on JSON in a bash variable, running `gron -v` also is cumbersome enough for me to want to use another tool.
So, I still like `gron`, I just think it has a rather small niche. One that maybe could be a bit larger if there was a way for it to output delimited records with user-specified delimiters (provided you know the output enough to be sure they don't appear in any strings).
jq is powerful, but it's nowhere simple.
I get the sentiment but to me it looks like everything looks like a nail when you only have a hammer.
Those are fine tools for an ad-hock one-liner. But if you're building something that doesn't fit into a line or two in the terminal you're better of with a proper scripting language. I don't care what it is — Python, Perl, Ruby, JavaScript, whatever — anything's better than Shell script. Shell is just too brittle with too many gotchas and edge cases. It's extremely hard to write more than about 10 lines of shell script without bugs. It's even harder to write if you don't know your exact shell. The only exception is that you know your script has to be executed on a system that only has a shell on it and you absolutely can not install/require any other interpreter.
> Then, it parses the JSON with the aforementioned Unix staples in a for loop. Show the damn code. Otherwise I'm just going to presume that the awk&sed reimplemented Json parsing in an indecipherable, buggy way.
It's really convenient when you can get away with stuff like that, and even if it's not a "proper" solution, at the end of the day it really doesn't always have to be.
jq is definitely tough to learn, I can never remember it. But, the whole argument against jq as a unitasker not worth learning and traditional unix tools being better is weird. Traditionally Unix tool mentality was “do one thing only and do it well” then pipe it together. jq fits perfectly into the Unix toolset.
Also, Alton Brown doesn't advise against unitaskers because he's some kind of hater. The reason you don't have unitaskers in the kitchen is because they take up physical space. You have to decide which tools are worth the space they take up, and it's hard to justify that for a tool you will only use once in a while. That's not a concern with computers any more, so the reasoning doesn't apply here.
I wonder if the script created by the author would go through edge cases of JSON, like escaped characters. I doubt and this sounds like a famous joke to me: Do you wanna hear a joke? Parsing XML with regexp I did it too. But this was nightmare
Definitely not. I wrote it to parse the already very nicely formatted output that I had. For example to get value B so I could search replace based on value D, when values A,B,C,D, are in order on separate lines.
valueb=$(grep D $json -B2| grep B)
now valueb = B when I started with D, and I can sed 's/B/D/' pretty easily. Now, the JSON I got were a big giant blog as it often is, I'd have had to at least use gron, which is a nifty tool I learned about by posting this here, and for that I'm grateful!
I wonder if the script created by the author would go through edge cases of JSON, like escaped characters. I doubt and this sounds like a famous joke to me: Do you wanna hear a joke? Parsing XML with regexp I did it too. But this was nightmare
Author here. Definitely not. I wrote it to parse the already very nicely formatted output that I had. For example to get value B so I could search replace based on value D, when values A,B,C,D, are in order on separate lines. valueb=$(grep D $json -B2| grep B) now valueb = B when I started with D, and I can sed 's/B/D/' pretty easily. Now, the JSON I got were a big giant blog as it often is, I'd have had to at least…
awk, sed etc. belong to the museum, now that we have so many tools and libraries that can handle structured data. The whole early Unix obsession with plain text files was a step in the wrong direction. One grating holdover of that is the /proc filesystem. Instead of a typed, structured api you get the stuff as text to be parsed, file system trees and data embedded in naming conventions.
In the /proc file system, they could have made the data format better even without using JSON though. (For example, null-terminated text strings might be better than using parentheses around it; since, then, what if the data includes parentheses? You could use the PostScript format for escaping (string literals in PostScript are written with parentheses around it, and can be nested), but, it would be better and simpler to not require any escaping, isn't it?
(Anyways, my own ideas of operating system design, one is that it does have structured data in a much better way, so avoids this and other problems. There is a common structure for most things, and would be designed to improve the efficiency compared with JSON, XML, etc, as well as other advantages. This can also be used inherently with the command shell, so unlike Nushell, the system is more designed for this.)