The issue is probably related to quotations among other shell related things. Observe:

    NAME=taterman
    [email protected]
    curl --jp "user=$NAME" --jp "email=$EMAIL" http://getdemtaters.com

vs

    curl -d "{\"user:\"$NAME\",\"email\":\"$EMAIL\"}" http://getdemtaters.com

Even adding jq to requirements doesn't make it that much better:

    jq -n --arg name "$NAME" --arg email "$EMAIL" '{ "user": $name, "email": $email }' | curl -d @-

it might be easier if you use heredoc

> Hmm… any actual use cases of this?

... interacting with APIs using cURL?

> I don’t find curl —jp a=b to be better than directly sending a payload on a HTTP resource

Getting JSON syntax right, error free, by hand, in a terminal, is not easy. The current equivalent of an eventual `curl --jp a=b` is

    curl -s -H "Content-Type: application/json" --data '{"a":"b"}'

that's a lot of opportunities for getting it wrong.

And even more when the JSON is dynamic, and not static: curl -jp a="$B"

> Getting JSON syntax right, error free, by hand, in a terminal, is not easy.

you are right and I wonder why shells haven't done anything to address this. Fish might, actually. colorization isn't really useful in aiding comprehension, but colorization is good at giving an indicator that there is a parse error somewhere.

its also pretty trivial to alias/wrap that tho