Lately, I have felt dissatisfied with jq for manipulating json in the command line and in scripts.
The personal reason, is that I like investing in tools that have withstood the test of time and I like learning them well.<\/p>\n\n\n\n
One example of these tools is vim. Learning vim has had a great payoff, and part of its charm is that, if I grow tired of it I can still transfer my knowledge of the vim key bindings to other tools or editors. I could move to Neovim, or if I’m more interested in writing text, I could use the key bindings in Obsidian. I have seen plugins for vim in VS Code, JetBrains, etcetera. And having studied vim, understanding a tool like grep is natural g\/re\/p (I do know that g\/re\/p comes from ex).<\/p>\n\n\n\n
My point is that learning vim has been a safe bet with high return. The same is true for sed and awk. Yet, here is jq, that claims to be a “jq is like sed for JSON data – you can use it to slice and filter and map and transform structured data with the same ease that sed, awk, grep and friends let you play with text.” But jq does not resemble anything of sed, awk or grep. I can’t transfer my knowledge of sed, awk or grep to jq.<\/p>\n\n\n\n
That why, I started working on JED (json sed). My objective is to create a json parsing tools that feels like home for sed power users. And if I do it correctly, the benefits would be evident: not because of the tools itself, but because sed is great.<\/p>\n\n\n\n
What I have in mind is something like this, let’s start with a simple json:<\/p>\n\n\n\n