71–80 of 107 posts
On a side note, for all my daily download tasks (other than debugging some web API) I've settled with aria2[0]. It seems to support every protocol used in modern Internet and has plenty of flexibility (connection multiplexing, bandwidth control etc.). It can even serve as 24/7 torrent client managed via remote API. 0. https://aria2.github.io/
Earlier quoted context omitted.
> the good old "curl | bash" I would be thankful if the habit of trusting a random IP with control of one's shell could die, forever.
Why would you be using a random ip? That incantation is usually used with a URL where you would have just downloaded and installed the software manually anyway. There are various arguments against the curl-piped-to-shell idiom but "random ip" doesn't seem like a valid one.
Building a script that acts differently for a web browser, a normal download, and curl, is trivial, and I've seen it happen. Here's a proof-of-concept[0] someone else wrote.
Manually downloading is safer, at least you can review, curling straight into a shell is inherently unsafe.
The better option is still a package manager, but curling straight to a shell is very unsafe.
[0] https://jordaneldredge.com/blog/one-way-curl-pipe-sh-install...
One thing I am always sure to share with collegues when we discuss curl, is the fact from the command line you can generate the underlying C code. This is pretty useful when creating a CLI for pretty much any app, and I've used it regularly to generate a CLI for an app. My post on how to do it: http://austingwalters.com/export-a-command-line-curl-command...
Imagine something like this with curl:
curl Alas, AFAIK, pipelining is still not enabled in the curl binary.
As I understand it, the --libcurl option only generates code for what is possible with the curl binary, e.g., curl_easy_init(), curl_easy_setopt(), etc.
As such, it will not generate code using curl_multi_init(), curl_multi_setopt(), etc.
I have to automate the code generation myself.
One thing I am always sure to share with collegues when we discuss curl, is the fact from the command line you can generate the underlying C code. This is pretty useful when creating a CLI for pretty much any app, and I've used it regularly to generate a CLI for an app. My post on how to do it: http://austingwalters.com/export-a-command-line-curl-command...
Earlier quoted context omitted.
That seems like a tool designed for a very specific use-case (JSON APIs), rather than the general-purpose protocol interaction of cURL. The fact that it appears to be doing some things "behind your back" to be "helpful" like reordering headers or otherwise manipulating the data would certainly be unwanted in a general-purpose tool.
True. But for those of us who work with JSON APIs more-often-than-not it's very good. Being able to simply pipe in a file as a payload saves me a lot of time. I know cURL does 1001 other things too, so the two tools aren't really in competition. HTTPie is more akin to Postman or Insomnia.
curl 'https://raw.githubusercontent.com/LearnWebCode/json-example/... | jq '.'
Earlier quoted context omitted.
HTTPie is great, but sometimes you need curl. Curl supports a lot more protocols.
Plus, it's easy to forget that httpie is SLOW. Sometimes when testing an API the timings are worrying, until you remember and switch over to cURL to confirm everything is right with the world.
There has been some work recently to make the interpreter start faster. I hope we will see the result in Python 3.7.
Either the Curl developers are at fault somewhere, which I somehow doubt, or distributions are really special snowflakes, which I also doubt, or software distribution in the Open Source world is, in my opinion, flawed: > Finally, I’d like to add that like all operating system distributions that ship curl (macOS, Linux distros, the BSDs, AIX, etc) Microsoft builds, packages and ships the curl binary completely indepen…
Earlier quoted context omitted.
It's because windows line endings are actually the technically correct one. Ever tried raw output to terminal?
I go back and forth on this. On the one hand, you're right in that you need both a line feed and a carriage return to actually "start a new line" (+1 to Windows). On the other, it seems wasteful to have two characters do a job that, in text files, could be just as easily done by one; editing and storing text is not the same as printing it, especially when the print incantation is a vestige of mostly-obsolete hardware…
One thing I am always sure to share with collegues when we discuss curl, is the fact from the command line you can generate the underlying C code. This is pretty useful when creating a CLI for pretty much any app, and I've used it regularly to generate a CLI for an app. My post on how to do it: http://austingwalters.com/export-a-command-line-curl-command...
It wasnt until 2006 that curl added HTTP/1.1 pipelining support. Hence I always used netcat instead of curl because I utilised pipelining heavily for text/html retrieval (IME, most servers supported it). Imagine something like this with curl: curl where curl only opens a single connection. Alas, AFAIK, pipelining is still not enabled in the curl binary. As I understand it, the --libcurl option only generates code for…
For debugging on remote servers this is pretty handy (at least, one it makes its way into the server versions). Now I have hope they'll put in a text editor that understands unix line endings.
It's like they're trying to get a record by not doing that. For years I've been baffled why Notepad at the very least couldn't understand unix line endings.
Probably the same reason that the CMD shell is so bad, and is only now being fixed up: since Windows is proprietary, nothing can be improved unless either the Microsoft decision-makers that are responsible for the product choose to spend budget on it, or there is a directive from higher-up in the company.