I like the output formatting or Curlie and also its HTTPie-like syntax sugar but sometimes, I have a curl command in my clipboard and would love to paste it to Curlie, something like this:

curlie --raw -H 'Some-Header: ABC' https://example.com

Do you think this would be possible? I can imagine some challenges around various curl flags but generally, it would be very useful if Curlie understood some of the basic curl switches.

Would you mind cutting a new release for v1.4.1?

Tokens directly available at https://github.com/settings/tokens

export GITHUB_TOKEN=xxxx

git clone [email protected]:rs/curlie.git
pushd curlie
    git tag -a v1.4.1 -m "Windows, color, and version updates"
    git push --tags

    goreleaser

I realize that you've done this several times already, but I thought giving the copy/paste might make it more convenient.

• Add version from git tags (must be built with go generate ./...).

  curlie version
  

  curlie v1.4.1-pre0+dirty (2020-09-12T02:46:46-06:00)
  

• Do not generate Linux-specific args.go on darwin.
• Ignore xversion.go (so that clean tags will produce clean output)

I'm working on publishing curlie to https://webinstall.dev/curlie (and I'll PR as an additional install method once I'm done), but I need to know what version of curlie is presently installed to know whether or not to re-install a new version.

How can I tell which version is the installed version?

This gives me the curl version only:

curlie --version

When using curlie in a script, I have an issue due those lines where it unconditionally tries to read from stdin, even if I try to close the standard input in my script before calling curlie.

Due to the way the endpoint I'm trying to call works, this leads to a 404 because of it.

A flag to disable that automatic behavior sounds like a good fix to me.

Httpie is smart enough to transform requests with the --form flag into actual form requests. Instead of parsing their arguments as JSON, they parse them as form fields. This commit enables the same thing for curlie

Note: This is my first time using Go in any capacity and my mastery of curl is pretty lacking, so feel free to cancel this in favor of some other approach. I'm also open to any feedback

curlie --version shows

curl 7.82.0 (x86_64-pc-linux-gnu) libcurl/7.82.0 OpenSSL/1.1.1m zlib/1.2.11 brotli/1.0.9 zstd/1.5.2 libidn2/2.3.2 libpsl/0.21.1 (+libidn2/2.3.0) libssh2/1.10.0 nghttp2/1.47.0
Release-Date: 2022-03-05

instead of

curlie 1.6.7 (x86_64-pc-linux-gnu) libcurl/7.82.0 OpenSSL/1.1.1m zlib/1.2.11 brotli/1.0.9 zstd/1.5.2 libidn2/2.3.2 libpsl/0.21.1 (+libidn2/2.3.0) libssh2/1.10.0 nghttp2/1.47.0
Release-Date: 2022-03-05

I am trying to run a POST request in vanilla cURL, but failing at it. I can easily run it in curlie (I expect the 500):

$ curlie -v -H 'X-SLURM-USER-TOKEN: someLongToken' -H 'X-SLURM-USER-NAME: lmdamato' -X POST -d '{"job":{"environment":{"LD_LIBRARY_PATH":"/lib/:/lib64/:/usr/local/lib","PATH":"/bin:/usr/bin/:/usr/local/bin/"},"name":"my_test_hello_world_job","partition":"QT","qos":"medium"},"script":"#!/bin/bash\n/bin/hostname"}' http://myslurmhost:6820/slurm/v0.0.37/job/submit
*   Trying 127.0.0.1...
* TCP_NODELAY set
* Connected to myslurmhost (127.0.0.1) port 6820 (#0)
POST /slurm/v0.0.37/job/submit HTTP/1.1
Host: myslurmhost:6820
User-Agent: curl/7.61.1
X-SLURM-USER-TOKEN: someLongToken
X-SLURM-USER-NAME: lmdamato
Content-Type: application/json
Accept: application/json, */*
Content-Length: 217

{
    "job": {
        "environment": {
            "LD_LIBRARY_PATH": "/lib/:/lib64/:/usr/local/lib",
            "PATH": "/bin:/usr/bin/:/usr/local/bin/"
        },
        "name": "my_test_hello_world_job",
        "partition": "QT",
        "qos": "medium"
    },
    "script": "#!/bin/bash\n/bin/hostname"
}


* upload completely sent off: 217 out of 217 bytes
HTTP/1.1 500 INTERNAL ERROR
Connection: Close
Content-Length: 385
Content-Type: application/json

* Closing connection 0
{
    "meta": {
        "plugin": {
            "type": "openapi\/v0.0.37",
            "name": "Slurm OpenAPI v0.0.37"
        },
        "Slurm": {
            "version": {
                "major": 21,
                "micro": 7,
                "minor": 8
            },
            "release": "21.08.7"
        }
    },
    "errors": [
        {
            "error_code": 5005,
            "error": "Zero Bytes were transmitted or received"
        }
    ]
}

But the exact same command in vanilla cURL won't work:

$ curl -v -H 'X-SLURM-USER-TOKEN: someLongToken' -H 'X-SLURM-USER-NAME: lmdamato' -X POST -d '{"job":{"environment":{"LD_LIBRARY_PATH":"/lib/:/lib64/:/usr/local/lib","PATH":"/bin:/usr/bin/:/usr/local/bin/"},"name":"my_test_hello_world_job","partition":"QT","qos":"medium"},"script":"#!/bin/bash\n/bin/hostname"}' http://myslurmhost:6820/slurm/v0.0.37/job/submit
Note: Unnecessary use of -X or --request, POST is already inferred.
*   Trying 127.0.0.1...
* TCP_NODELAY set
* Connected to myslurmhost (127.0.0.1) port 6820 (#0)
> POST /slurm/v0.0.37/job/submit HTTP/1.1
> Host: myslurmhost:6820
> User-Agent: curl/7.61.1
> Accept: */*
> X-SLURM-USER-TOKEN: someLongToken
> X-SLURM-USER-NAME: lmdamato
> Content-Length: 217
> Content-Type: application/x-www-form-urlencoded
> 
* upload completely sent off: 217 out of 217 bytes
< HTTP/1.1 400 BAD REQUEST
< Connection: Close
< Content-Length: 22
< Content-Type: text/plain
< 
* Closing connection 0
Unable to parse query.

Can someone help me understand why?

When I am using the newer curl option aws-sigv4, curlie interprets it as headers:

curlie https://REDACTED.execute-api.eu-west-1.amazonaws.com/REDACTED --curl --aws-sigv4 "aws:amz:eu-west-1" --user "$(aws configure get aws_access_key_id):$(aws configure get aws_secret_access_key)"

curl --aws-sigv4 --user REDACTED:REDACTED -H aws:amz:eu-west-1 https://REDACTED.execute-api.eu-west-1.amazonaws.com/REDACTED -s -S -v -H "Accept: application/json, */*"

Fixed issue #29

For windows runtime, added originalMode or ENABLE_VIRTUAL_TERMINAL_PROCESSING in SetConsoleMode, and if case of any error, disabled color print.

The current version of the code forwards all operations to curl using exec.Command which has been found to be vulnerable to an issue involving PATH lookups in untrusted directories that can lead to remote execution. The vulnerability is well described in the following blog post written by Russ Cox on Jan 19th, 2021 → Command PATH security in Go.

curl allows users to support cookie based sessions with the --cookie-jar and --cookie flags.

httpie has similar functionality with the --session flag.

Are there any plans to add similar functionality with curlie?

If there is already a way to do this (since curlie is a wrapper around curl), I'm not seeing a way to do this in the docs.

When no explicit Accept header nor any json payload (e.g., foo=bar, quz=42) are specified in the request, the following is a difference in handling wrt httpie:

$ curlie -v get http://example.net
* ...
GET / HTTP/1.1
Host: example.net
User-Agent: curl/7.64.1
Accept: application/json, */*

HTTP/1.1 200 OK
...

That is, curlie includes and gives preference to application/json in the Accept header in these cases. In contrast, httpie simply includes Accept: */*, which seems more flexible in general:

$ http -v get http://example.net
GET / HTTP/1.1
Accept: */*
Accept-Encoding: gzip, deflate
Connection: keep-alive
Host: example.net
User-Agent: HTTPie/3.2.1
...

fwiw, CURL itself also just includes Accept: */*:

➜  ~ curl -v http://example.net
*   Trying 2606:2800:220:1:248:1893:25c8:1946...
* TCP_NODELAY set
* Connected to example.net (2606:2800:220:1:248:1893:25c8:1946) port 80 (#0)
> GET / HTTP/1.1
> Host: example.net
> User-Agent: curl/7.64.1
> Accept: */*
>
...

Thank you for curlie ❤️ I find myself stumbling over curl's behavior of returning a 0 exit code when a >= 400 status code was returned from the server. The -f parameters solves that issue for me but supplying it to every curlie command is tedious. I was wondering whether you'd find it acceptable to supply parameters via environment variables or even a configuration file.

Normally curlie returns output like that (as expected):

[mateusz@arch curlie (fix)]$ curlie localhost:8080
HTTP/1.1 200 OK
Date: Fri, 20 May 2022 19:35:04 GMT
Content-Length: 30
Content-Type: text/plain; charset=utf-8

Hello
Hello
Hello
Hello
Hello

But sometimes it returns like so: (around 5% of responses)

[mateusz@arch curlie (fix)]$ curlie localhost:8080
Hello
Hello
Hello
Hello
Hello
HTTP/1.1 200 OK
Date: Fri, 20 May 2022 19:35:40 GMT
Content-Length: 30
Content-Type: text/plain; charset=utf-8

For me it only happens when querying localhost (probably because of the low latency??). This PR fixes it.