21–30 of 100 posts
This is cool. In the spirit of "do one thing well", I'd so rather use this to construct JSON payloads to curl requests than the curl project's own "json part" proposal[1] under consideration. [1]: https://github.com/curl/curl/wiki/JSON#--jp-part
>Bam! Jo tries to be clever about types and knows null, booleans, strings and numbers. I'm very skeptical of this. If I put x=001979 in as a value I dont think I want you trying to guess if that's supposed to be an integer or a string. This sounds like the Norway Problem waiting to happen.
jo -- -s opaque_id=001979
{"opaque_id":"001979"}>Bam! Jo tries to be clever about types and knows null, booleans, strings and numbers. I'm very skeptical of this. If I put x=001979 in as a value I dont think I want you trying to guess if that's supposed to be an integer or a string. This sounds like the Norway Problem waiting to happen.
>Bam! Jo tries to be clever about types and knows null, booleans, strings and numbers. I'm very skeptical of this. If I put x=001979 in as a value I dont think I want you trying to guess if that's supposed to be an integer or a string. This sounds like the Norway Problem waiting to happen.
But, clearly there is a use-case for producing json with integer, null, and boolean values.
This is cool. In the spirit of "do one thing well", I'd so rather use this to construct JSON payloads to curl requests than the curl project's own "json part" proposal[1] under consideration. [1]: https://github.com/curl/curl/wiki/JSON#--jp-part
Agree, I was surprised that the cURL feature was considered as it seems to go against the "Do One Thing" and composability points of the UNIX philosophy.
Curl does do one thing: make network requests. This feature is making it easier to make network requests, i.e. it makes it better at doing the one thing that it does.
>Bam! Jo tries to be clever about types and knows null, booleans, strings and numbers. I'm very skeptical of this. If I put x=001979 in as a value I dont think I want you trying to guess if that's supposed to be an integer or a string. This sounds like the Norway Problem waiting to happen.
It is reminiscent of a feature in YAML that has bitten people. But, clearly there is a use-case for producing json with integer, null, and boolean values.
>Bam! Jo tries to be clever about types and knows null, booleans, strings and numbers. I'm very skeptical of this. If I put x=001979 in as a value I dont think I want you trying to guess if that's supposed to be an integer or a string. This sounds like the Norway Problem waiting to happen.
then use -s : jo -- -s opaque_id=001979 {"opaque_id":"001979"}
Avoid using this command in prod.
"If the first version of your shell script is more than five lines long, you should have written it in Python."
I think there's a lot of truth in that. None of the examples presented in the article look better than had they been written in some existing scripting/programming language. In fact, had they been written in Python or Javascript, it would have been far more obvious what the resulting output would have been, considering that those languages already use {} for objects and [] for lists.
For example, take this example:
jo -p name=JP object=$(jo fruit=Orange point=$(jo x=10 y=20) number=17) sunday=false
json.dumps({"name": "JP", "object": {"fruit": "Orange", "point": {"x": 10, "y": 20}, "number": 17}, "sunday": False})
The more I work with JSON, the more I crave some kind of dedicated json editor to easily visualize and manipulate json objects, and to serialize / deserialize strings. This is especially the case with truly massive JSON objects with multiple layers of nesting. Anyway, cool tool that makes one part of the process of whipping up JSON a little less painful
https://play.google.com/store/apps/details?id=com.alexsci.an...