I'd be interested to see if many others on here do prefer curl over wget for pulling binary files.
This is how I ended up consistently prefering curl:
Last time I looked closely, I had better control with curl, and curl had better support for stuff. For example HTTP 1.1 was supported by curl, but not wget.
This makes curl a far better choice for testing HTTP servers.
And next, since I now know curl pretty well, and have it installed all over the place, it is my go-to HTTP command line client. I don't know of any reason to use both, or any reason to prefer wget, although in some situations maybe "wget <url>" acts slightly more like you want than "curl <url>". (Which is of course easy to work around by using "curl -OL <url>", if that's what you want, but convenient defaults are still convenient)
> "Last time I looked closely, I had better control with curl, and curl had better support for stuff. For example HTTP 1.1 was supported by curl, but not wget.
"This makes curl a far better choice for testing HTTP servers."
Well yes. You're just reiterating what I said about curl being great for server testing. But this article is about download performance. When just downloading a largish binary file (eg a tarball), it's easier to just:
wget example.com/source.tar.gz
With that, you get a progress bar, it saves the file to disk and basically just does all the sane options you'd want for downloading by default (which I think is why most INSTALL / README docs tend to recommend wget in their instructions).
Again, I'm not saying one is better than the other, but the convenience of wget's defaults (which I think you also highlighted later in you post) does tend to make me favour it for downloading binary content (with curl being my go-to for any server testing or text resources).
> "And next, since I now know curl pretty well, and have it installed all over the place, it is my go-to HTTP command line client."
wget also comes as part of the basic install with almost all Linux and other UNIX-like OSs as well. In fact wget actually pre-dates curl (albeit they're both >= 15 years old, so there's not really much between the two relatively speaking) so I'd have expected even your oldest live systems would still have wget.
I can totally relate to the "know[ing] curl pretty well" point though. There is definitely an argument for reusing the tools that you're already familiar with.
We seem to be in full agreement. I only wanted to spell out my own reasoning for using curl and not wget, since you explicitly said you were interested in this information, and I suppose there are others that think like me in this regard as well :)
One popular UNIX-like OS that comes with curl and not wget is OS X. That might also drive adoption.
(I seem to remember having had to install both curl and wget on Ubuntu, but I am unable to verify this now)
> "We seem to be in full agreement. I only wanted to spell out my own reasoning for using curl and not wget, since you explicitly said you were interested in this information, and I suppose there are others that think like me in this regard as well :)"
I'm grateful for your input. Sorry if I came across as elitist - that wasn't my intention but in reflection, in does read a little that way.
> "One popular UNIX-like OS that comes with curl and not wget is OS X. That might also drive adoption."
Ahh interesting point. I guess that would have an impact.
Comments
This is how I ended up consistently prefering curl:
Last time I looked closely, I had better control with curl, and curl had better support for stuff. For example HTTP 1.1 was supported by curl, but not wget.
This makes curl a far better choice for testing HTTP servers.
And next, since I now know curl pretty well, and have it installed all over the place, it is my go-to HTTP command line client. I don't know of any reason to use both, or any reason to prefer wget, although in some situations maybe "wget <url>" acts slightly more like you want than "curl <url>". (Which is of course easy to work around by using "curl -OL <url>", if that's what you want, but convenient defaults are still convenient)
> "Last time I looked closely, I had better control with curl, and curl had better support for stuff. For example HTTP 1.1 was supported by curl, but not wget.
Well yes. You're just reiterating what I said about curl being great for server testing. But this article is about download performance. When just downloading a largish binary file (eg a tarball), it's easier to just:
With that, you get a progress bar, it saves the file to disk and basically just does all the sane options you'd want for downloading by default (which I think is why most INSTALL / README docs tend to recommend wget in their instructions).Again, I'm not saying one is better than the other, but the convenience of wget's defaults (which I think you also highlighted later in you post) does tend to make me favour it for downloading binary content (with curl being my go-to for any server testing or text resources).
> "And next, since I now know curl pretty well, and have it installed all over the place, it is my go-to HTTP command line client."
wget also comes as part of the basic install with almost all Linux and other UNIX-like OSs as well. In fact wget actually pre-dates curl (albeit they're both >= 15 years old, so there's not really much between the two relatively speaking) so I'd have expected even your oldest live systems would still have wget.
I can totally relate to the "know[ing] curl pretty well" point though. There is definitely an argument for reusing the tools that you're already familiar with.
We seem to be in full agreement. I only wanted to spell out my own reasoning for using curl and not wget, since you explicitly said you were interested in this information, and I suppose there are others that think like me in this regard as well :)
One popular UNIX-like OS that comes with curl and not wget is OS X. That might also drive adoption.
(I seem to remember having had to install both curl and wget on Ubuntu, but I am unable to verify this now)
> "We seem to be in full agreement. I only wanted to spell out my own reasoning for using curl and not wget, since you explicitly said you were interested in this information, and I suppose there are others that think like me in this regard as well :)"
I'm grateful for your input. Sorry if I came across as elitist - that wasn't my intention but in reflection, in does read a little that way.
> "One popular UNIX-like OS that comes with curl and not wget is OS X. That might also drive adoption."
Ahh interesting point. I guess that would have an impact.