I like the idea of this, but the actual implementation seems to have some serious issues.
If I were to use this tool, it would be to construct a JSON object in a shell script where I know the keys I want and the types they should have, but get the values dynamically somehow. However, jo seems to be completely unsuited for that; say I had this typical script:
name="$1"
curl -X POST https://submit-post.example.com --data "$(jo -- -s name="$name")"
jo -- -s key=value tells jo that value should be a string. Omitting this part would mean jo automatically guesses based on value, which is a pretty big footgun, but at least it can sort of be avoided. However, even with the -s, it will treat any string starting with a { as a nested object, so if name is "{}", the JSON object created will be {"name":{}} - name is an empty object instead of the string "{}".
It’s a plague in the world of shell scripting that the obvious way to do something works in 80% of cases but randomly breaks, the less obvious way works in 96% of cases but also randomly breaks, and the actually correct solution is either impossible or really hard. It seems like jo continues this tradition.
The article mentions that it’s a good companion to jq. Personally, I’m already using jq for constructing JSON[1]. After reading the article and looking the Github repo of jo, I’m afraid I don’t see what it adds when already using jq.
Bonus points: It’s also really nice to use jq with live queries in Emacs[2].
jo is ok up to a point. I had troubles making key/values pair when values had equal sign…
jq doesn’t seem as an elegant solution to create JSON when data needs to come from Bash variables.
I like the idea of this, but the actual implementation seems to have some serious issues.
If I were to use this tool, it would be to construct a JSON object in a shell script where I know the keys I want and the types they should have, but get the values dynamically somehow. However,
joseems to be completely unsuited for that; say I had this typical script:jo -- -s key=valuetells jo thatvalueshould be a string. Omitting this part would mean jo automatically guesses based on value, which is a pretty big footgun, but at least it can sort of be avoided. However, even with the-s, it will treat any string starting with a{as a nested object, so if name is"{}", the JSON object created will be{"name":{}}-nameis an empty object instead of the string"{}".It’s a plague in the world of shell scripting that the obvious way to do something works in 80% of cases but randomly breaks, the less obvious way works in 96% of cases but also randomly breaks, and the actually correct solution is either impossible or really hard. It seems like jo continues this tradition.
libxo, part of FreeBSD base, also has a
xocommand for outputting structured data from shell scripts while still supporting normal plaintext output.Can it be compiled for macos?
EDIT: yep, and it works. :)
Thanks for sharing this, seems really nice! Hopefully, it gets ported to Linux.
Have you tried building it? It builds fine under macos, so there is a non-zero chance for the same outcome for Linux. :)
The article mentions that it’s a good companion to jq. Personally, I’m already using jq for constructing JSON[1]. After reading the article and looking the Github repo of jo, I’m afraid I don’t see what it adds when already using jq.
Bonus points: It’s also really nice to use jq with live queries in Emacs[2].
jo is ok up to a point. I had troubles making key/values pair when values had equal sign… jq doesn’t seem as an elegant solution to create JSON when data needs to come from Bash variables.