The python utils section missed the very cool json.tool that can pretty print JSON files (and exists on your OS if it includes Python):
cat /tmp/foo.json | python -m json.tool
https://docs.python.org/3/library/json.html#module-json.tool
cat /tmp/foo.json | python -m json.tool
https://docs.python.org/3/library/json.html#module-json.tool
It's a very flexible tool for filtering, querying and manipulating JSON data, but when run with no arguments, it performs a no-op transformation that just pretty-prints its input.
impossible to understate the value in: not frequently fucking up your ability to run the critical/mundane/everyday/musclememory commands you've come to rely on after maybe 100+ invocations/week as far back as you can remember just because someone you've never met wanted to bump the .ruby-version in your java monorepo
I’ve unfortunately often seen coworkers spend half an hour painstakingly crafting and debugging a jq query, that could have been cobbled together in a few minutes with grep and sed.
I think the issue is that jq’s interface makes it really hard to “narrow in” on the right solution, whereas grep is much more forgiving.
Or 'jq', if you include the binary name.
Hardly "bloated".
jq is something i've hated learning but powerful beyond tying grep and awk together.
jq is a tool, and like every tool, requires some upfront learning. Once mastered its much more productive than the grep/awk/friends solution.
Take this example JSON
<pre> { "code": 42, "items": [ { "type":"color", "name":"red", "rgb": [120, 2, 2 ]}, { "type":"color", "name":"green", "rgb": [2, 120, 2]} ] } </pre>
for instance, to grab the rgb field for the color green... jq -r '.items | .[] | select(.name=="green") | .rgb
I am implementing XPath in a tool called Xidel.
There the syntax for the example is much simpler: xidel - -e '?items ?* [?name="green"] ?rgb'
Depends what kabacha means with bloated. The XPath syntax is more verbose, but less cryptic
$ firefox --new-window somefile.json
$ python3 -m json.tool test.json> Characters saved with "<"? 3. > Hours lost with accidental ">"? unbounded.
Preface: I'm confident on the shell & with my keyboard: I've been using shell redirects for a couple decades, learned touch-typing up to around 80WPM, and used to note-take math lectures live in latex. Yes, I have noclobber enabled. But...
I can't promise myself I'm on a machine configured that way OR that I won't typo this one on a file that really matters.
I kinda use of `cat` as a `immutability-please` command: it _creates_ a barrier/seam between this file and whatever I'm doing with it, such that I'm _guaranteed_ nothing downstream will mutate it (as long as everything only works on stdio).
In a kinda similar way: by starting with `cat x |` (or even just `cat x`, frequently!), the rest of that compound command is _input source independent_ (and even _ignorant_!) -- if I want to hook it up later to a `curl example.com/xyz.json`, I don't need to split it into separate commands/introduce temp files/etc. This is especially because I find myself doing a _really_ quick scan of the entire file ("did it return the actual object this time or just `{}`?"), then piling on transforms from there.
Something about doing `cat x | head` and then kill-wording to fill in `next-thing` feels faster and more consistent than `head x` and then `next-thing x`, maybe because the filenames are often much longer than the commands? Maybe I need a "go to start of line, forward-kill one word" hotkey?
tl;dr: i'm playing psychological games with myself and TBH not sure I'm coming out ahead.
grep <file -opts 'regex'
I think I still have the “wrong” preference, but I appreciate learning some new stuff!