I like jq (https://stedolan.github.io/jq/) for this purpose.

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.

jq doesn't come pre-installed with every OS, python's json.tool does. So it's always there when you need it, no installation required, which is why I put it the same category of all those classic command-line tools.

I don’t actually believe my last Linux install came with a system Python. And as a Python developer I always end up using some tool or another to manage installations of multiple Python versions anyway. Furthermore jq just works as a classic command-line tool.

> ... just works as a classic command-line tool.

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

What Linux distro do you use that it doesn't have Python on it?

Ubuntu but I think the same was true for Arch.

What? Half of Ubuntu's internal stuff is written in Python. They've switched to Python 3 but I've never heard of Ubuntu without Python.

I’m sure that’s true and maybe I’m misremembering but I still think I had to apt install a Python runtime I could actually invoke from the shell.

jq is yet another bloated syntax to learn and I'd definitely refrain from suggesting it to anyone whos not working with json everyday.

I tend to agree, regretfully.

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.

I agree in the general case, but the syntax for pretty printing which is what he is doing is literally nothing.

Or 'jq', if you include the binary name.

Hardly "bloated".

i dont know if i'd call its syntax bloated at all.

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

An alternative would be to use XPath 3.1.

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

Agreed about the bloated syntax bit. Whenever I need to work with jq , I tend to trial with jid first and then use the actual syntax with jq. Convoluted if you think about it....

Firefox has quite a nice interactive JSON viewer, built in.

Which doesn't help on the command line.

Invocation from command line:

  $ firefox --new-window somefile.json

The viewer does however suffer from poor scaling with file size.

but you are out of command-line once you do that. The whole point of this guide is that you can combine all these tools together.

Thank you for this suggestion -- it is now included in the slides.

Don't abuse cats, use `python3 -m json.tool < test.json` instead.

Why go to all that extra effort to type a "<" character?

    $ python3 -m json.tool test.json

Bit of pointless contrarian opinion from a long time cat|'r:

> 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.

Wow, you described my workflow exactly. Using "<" might be shorter and faster-for-the-machine, but it's less readable and breaks the left-to-right order. I also frequently start with `cat x`, see what's in the file, move on to `cat x | some filter` etc.

'<file' can be used anywhere in the command. If it makes more human sense to have the file near the start, you can do that.

grep <file -opts 'regex'

This is why I walked back my claims a bit in my tldr — basically started trying stuff out and had a “whoa not used to the way that looks, but it does _work_...” moment.

I think I still have the “wrong” preference, but I appreciate learning some new stuff!

cat was just to demonstrate using it on streams. A more common use case would be to pipe some curl to it to see some API output, or grep some log file.