51–60 of 107 posts
Cool, now I don't need to remember the arcane incantation to download a file with Powershell. Do you think we'll see things like the good old "curl | bash" for Windows now? They still have no package manager worth using.
I would be thankful if the habit of trusting a random IP with control of one's shell could die, forever.
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...
Cool, now I don't need to remember the arcane incantation to download a file with Powershell. Do you think we'll see things like the good old "curl | bash" for Windows now? They still have no package manager worth using.
> 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.
Cool, now I don't need to remember the arcane incantation to download a file with Powershell. Do you think we'll see things like the good old "curl | bash" for Windows now? They still have no package manager worth using.
Curl is alright, and congratulations on this massive and very impressive step forwards, but the CLI not exactly very user friendly. httpie[1] is a great tool if you find curl invocation somewhat arcane. 1. https://httpie.org/
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.
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.
Cool, now I don't need to remember the arcane incantation to download a file with Powershell. Do you think we'll see things like the good old "curl | bash" for Windows now? They still have no package manager worth using.
Have you tried chocolatey? I’ve really enjoyed using it
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…
People have pointed out tons of reasons why distros do their own builds, but really I don't understand what would possibly be a reason not to!?
The build system itself also is just a piece of software that gets distributed along with the source of the software to be built, and just as you can download and run curl and get a predictable result (the download of some URL), you can download and run the curl build system and get a predictable result (a cURL binary).
So, in that regard, what does it matter what execution of the cURL build system your cURL binary came from?
In particular with the trend towards reproducible builds, where the build result will be bit-identical between different runs of the build system if it's using the same compiler (version), I just don't see why you care!?
Yeah, distros shouldn't just modify the software they package willy-nilly, but that's completely orthogonal to whether they should do their own builds. There are many reasons for applying small changes to enable integration with the distro, and in particular it's just unreasonable to expect that everyone of the thousands of upstream authors or Debian packages, say, operate machines of all ten CPU architectures that are currently supported by Debian so they can provide binaries for all architectures. So, if you want to be able to distribute software written by people who don't happen to have a System z or a MIPS machine in Debian, maintainers have to prepare packages in such a way that binaries for those architectures can be built--and if they do that, it's trivial to also build all the other architectures from the same source. Adding special cases for when a binary is already available for some architecture from upstream would be just completely pointless complexity.
What would be the reason behind disabling all those protocols?
Probably to reduce exposure to security issues. The more code you ship, the more code you're responsible for keeping secure. Looking briefly at the list at https://curl.haxx.se/docs/security.html I see issues for FTP (x2), IMAP, and TFTP in 2017 alone. These protocols which are outside of curl's core competency of http are likely to have less scrutiny and more bugs. While FTP shouldn't be removed from curl I don't th…
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...
Cool, now I don't need to remember the arcane incantation to download a file with Powershell. Do you think we'll see things like the good old "curl | bash" for Windows now? They still have no package manager worth using.
Also, take a look at Chocolatey for package management. Yeah it's not a built-in thing, but it's pretty decent.