Hacker News Reader

Comment by hn_throwaway_99 | Hacker News Reader

The --jp (json part) command line option, described at https://github.com/curl/curl/wiki/JSON, has "anti-pattern" written all over it to me. Why introduce some specific, curl-only wonky-ish version of JSON? Is this any easier to remember than normal JSON? I mean, right now, I use cURL all the time with JSON posts, just doing something like

-d '{ "foo": "bar", "zed": "yow" }'

The proposed --jp flag seems worse to me in every way.

(Note I do like the --json as just syntactic sugar for -H "Accept: application/json" -d <jsonBody>)

View on HN

--jp is a perfect fit for shell scripting integration:

    bash$ curl ... --jp "foo=$foo" ...

This has zero shell-quoting, expansion, escaping, or separator issues. Whatever's in environment variable `foo` will be sent to the server as a single value associated with key `foo`, whether it's a zero-length empty string, or full of backslashes or spaces or newlines or whatever.

There are fancier ways to accept multi-arg, but they all have weaknesses, and this matches the way curl handles -H arguments already today (one per header, stack them if you want many), so I think it's a sound way to handle CLI arguments.

(I don't have any specific views on whether this is how curl should do JSON or not, but I recognized the CLI safety mechanism immediately.)

Does this handle nesting? I tend to do a lot of nesting in json. Almost always.

Yes, if you click through to the wiki page there are examples of nested lists, maps.

Then it will need quoting the metacharacters used for nesting.

I certainly hope not!

> Is this any easier to remember than normal JSON?

Yeah, actually it is. It's immediately intuitive to me. It makes string interpolation way easier. Quick, how do you do -d {object} and pass in environment variables with correct string escaping? Do you start with single quote or double quote? Where do I put backslashes? Bash vs zsh compatibility? Plus you have to make sure all the slashes, quotes, brackets and braces match.

--jp foo=$FOO --jp bar="baz-${BAR:-default-bar}" --jp date="\"$(date)\""

(I'm iffy on the last one, but it's WAY easier than trying to build that into an object)

> --jp date="\"$(date)\""

If it's going to properly crib `jo` syntax, you can just do `date="$(date)"` - no need for the second set of quotes (and, indeed, they'll mess it up.)

    > jo date="$(date)"
    {"date":"Thu 20 Jan 2022 20:59:16 GMT"}
    > jo date="\"$(date)\""
    {"date":"\"Thu 20 Jan 2022 21:00:28 GMT\""}

Realizing that I'm screaming into the wrong textbox, but "-H 'Accept: application/json'" is the wrong header for curl to set in that circumstance, since all that curl is able to say with authority is that the content-type it emitted is application/json, not what the user wants/accepts back. Maybe this feature is an example of the 80/20 rule, and that more advanced usages can't use --json and must still craft the explicit C-T and Accept headers

It is so weird that command-f on that wiki doesn't show a single content-type header

Actually, you are correct, I had a copy/paste error from pulling a different curl command and merging it, the curl page correctly shows it as `-d [whatever] -H "Content-Type: application/json"`

--jp doesn't even make sense as it's an abbreviation.. it's rather be --json-part.

The notation seems to be similar to HAML<>HTML. It's not JSON, and it doesn't make any sense other than really short ad hoc queries. It's just confusing and only solves a problem that a tiiiny amount of people have (regualar ad hoc json queries, where people are too lazy to actually write out json).

Otherwise, why not do the same for XML, css. Or heck.. why not simply support HAML as well

It's better to have such functionality extracted in some other tool and just pipe it

Yeah, it cries out to me for a separate `jp` tool instead, so you'd do:

    $ jp foo=bar zed=yow
    { "foo": "bar", "zed": "yow" }
    $ jp foo=bar zed=yow | curl --json - https://example.com/destination
    ...result here...

Why not use the UNIX idea of composability and relegate all the JSON construction to another tool, e.g `jo`:

    $ jo query="six times nine" answer=42 | curl --json -
    Sending JSON...
    {"query":"six times nine","answer":42}

Reply on news.ycombinator.com