Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Curl vs. Wget

daniel.haxx.se

Post reply on HN
Print view View original

141–150 of 205 posts

Re: Curl vs. Wget

#141

Post by vacri »

lomnakkus wrote: post #117
vacri wrote: post #114

Earlier quoted context omitted.

Nonsense. You can use both tools. 'curl' is 'cat url', and by default is meant to behave like 'cat' - that is, send stuff to STDOUT. 'wget' is 'web get', and gets an object from (only) the web or ftp, and plonks it on your filesystem. They both do exactly what they're supposed to (according to name), by default.

> 'curl' is 'cat url', Whoa... TIL something! I don't know if that's the official etymology, but that's a great mnemonic! EDIT: ... and yes, I use both tools :).

Well, it looks like I was taught wrong, and it's not 'cat URL' (though that's a good way to think of it), but the rather more direct-to-STDOUT-sounding 'see URL'. TIL something too :)

https://en.wikipedia.org/wiki/CURL

Re: Curl vs. Wget

#142

Post by lucb1e »

X-Istence wrote: post #132

I use curl because it is generally installed. I prefer not to install wget, especially on customer machines because it stops 90% of script kiddies. For some reason wget is the only tool they will attempt to use to download their sploit.

Pretty sure skiddies will not assume most victims have wget already, they'll just ship it with the exploit. If not installing wget is an annoyance to a hacker, they're already in too deep ;)

Re: Curl vs. Wget

#144

Post by cathexis »

hartator wrote: post #78

> Wget requires no extra options to simply download a remote URL to a local file, while curl requires -o or -O. I think this is oddly the major reason why wget is more popular. Saving 3 chars + not having to remember the specific curl flag seems to matter more than what we can think.

I'm always amused by people who do the opposite: using wget to send get/post requests to web servers and having to add `-O /dev/null' (or, even worse `-O - > /dev/null'to keep from saving the results.

Re: Curl vs. Wget

#145

Post by digi_owl »

koolba wrote: post #17
Xophmeister wrote: post #9

Earlier quoted context omitted.

Streaming to stdout is more Unix-y, allowing you to pipe the response into further processes. For example: curl http://api.example.com/json | jq '.["someKey"]' # etc., etc.

Or in modern idiomatically insecure install scripts: curl http://bogus.example.com/install | sudo bash

Too bad that is a reserved domain. Would be hilarious to put an actual shell script there that would echo ARF ARF ARF in a loop.

Re: Curl vs. Wget

#146

Post by technomancy »

timgilbert wrote: post #121
geerlingguy wrote: post #13

Also putting this out there—for nicer REST API interaction on the CLI, and a little more user-friendliness, you might also want to add HTTPie[1] to your toolbelt. It's not going to replace curl or wget usage, but it is a nicer interface in certain circumstances. [1] https://github.com/jkbrzt/httpie

HTTPie is amazing for working with JSON/REST interfaces. It's really succinct and generally designed with user-friendliness in mind, versus supporting every nook and cranny of the HTTP RFCs. It's installable via homebrew for Mac users. Whenever I go back to curl I feel the same minor aggravation I do when moving from homebrew back to apt (want to install? apt-get. Search? apt-cache search. List? dpkg. Remove? apt-get…

> want to install? apt-get. Search? apt-cache search. List? dpkg. Remove? apt-get again, for some reason

I think this is largely why aptitude exists; a single unified command for all common package tasks. Most of the Debian docs have been switched over to recommend its usage, but for some reason Ubuntu hasn't followed suit. That said, I just keep using the same old shell aliases I added in 2003 personally.

Re: Curl vs. Wget

#147

Post by cathexis »

JonathonW wrote: post #31

For my usage: * Wget's the interactive, end-user tool, and my go-to if I just need to download a file. For that purpose, its defaults are more sane, its command line usage is more straightforward, its documentation is better-organized, and it can continue incomplete downloads, which curl can't. * Curl's the developer tool-- it's what I'd use if I were building a shell script that needed to download. The command line…

Pretty much. If I want to save a file: wget. If I want to do _anything_ else: curl. Yes you can write files with curl, no I don't use that functionality very often. I don't think of them as "end user" vs "developer" use cases so much as them being two great tools for different tasks. I do wish that -s was the curl default, since that stderr progress output is pretty lame.

Re: Curl vs. Wget

#148

Post by nowprovision »

Unmentioned in the article - Curl supports --resolve, this single feature helps us test all sorts of scenarios for HTTPS and hostname based multiplexing where DNS isn't updated or consistent yet, e.g. transferring site, bringing up cold standbys, couldn't live without it (well I could if I wanted to edit /etc/hosts continuously)

Re: Curl vs. Wget

#149

Post by timClicks »

iglookid wrote: post #120
thrownaway2424 wrote: post #113

Earlier quoted context omitted.

wget is ludicrously good for mirroring. I use it to mirror the entirety of EDGAR. For my money another tool that belongs in the toolbox is perl's WWW::Mechanize and its component WWW::Mechanize::Shell.

How does wget compare with httrack for mirroring?

It's somewhat hard to compare CLI vs GUI programs.. but in my experience, wget --mirror is simpler than HTTrack for simple tasks, which takes a little bit of mucking around to start downloading. HTTrack has a smaller learning curve for more complex situations though.

Re: Curl vs. Wget

#150

Post by mschuster91 »

manyxcxi wrote: post #107
JonathonW wrote: post #31

For my usage: * Wget's the interactive, end-user tool, and my go-to if I just need to download a file. For that purpose, its defaults are more sane, its command line usage is more straightforward, its documentation is better-organized, and it can continue incomplete downloads, which curl can't. * Curl's the developer tool-- it's what I'd use if I were building a shell script that needed to download. The command line…

> This doesn't really need to be an "emacs vs. vim" or "tabs vs. spaces"-type dichotomy: wget and curl do different things well and there's no reason why both shouldn't coexist in one's workflow. Totally agree. I love curl for testing API request/responses manually. It's usually a huge part of navigating my way around a new API that doesn't have a client library available for whatever language I'm using at that time.…

Use the Chrome Postman extension together with Postman Interceptor. It's really awesome.
Post reply on HN