I use wget a lot. I don't use a desktop manager and I generally don't trust my web browser to do The Right Thing when I download various non-html files. I prefer using the command line so I always "Copy Link Adress" and then do whatever I want with it.

For instance when I download some archive I don't have to bother selecting where to download the file from the GUI (I hate navigating filesystems from GUIs), waiting for it to finish before switching to the command line to extract it. I just get the address, "curl $link | tar xzv" and I'm done.

Current versions of the chrome debugger (and maybe others!) will let you print out the curl command to retrieve a resource that is completely inaccessible in the web interface. If you keep a little media server like plex, et al, it's a really convenient tool for time shifting/stealing/whatever the word is some video on a website that won't let you at the video source. You just open the debugger, view the network resources, click play, sort by size, right click the one that is growing (the video), get the curl, paste it into a terminal with a -o flag, and now you have the video. Whether you should have it is another thread, not this one.

It sounds like maybe you are most familiar with GUIs or the web. Curl is a UNIX tool and doesn't work like those things. If it's the only unix tool you use, that might seem jarring.

Of course it would be a smoother experience for you if it worked more like the rest of the tools you are familiar with, but changing it would be a mistake. If curl were changed, then it would be one of the few unix tools that differs from the rest. That would make it jarring to people who use unix. Nobody wants to erode the good parts of unix and destroy the unix way just to make some commands slightly less jarring to people who don't regularly use unix.

Especially when you don't even need curl. That's the wrong option for you. Right next to the option in Chrome to copy a curl command is the option to copy just the url. Just use that and paste the url into your browser, which will work more like you'd expect.

If you must use curl, you almost certainly don't want to use "-o". That's an advanced option for when you are downloading multiple resources with a single command. You use it to provide a template for the multiple output filenames necessary in that particular situation.

If you only want to specify a single filename, then do like you would with any other typical unix command and redirect the output to a file. For example, append ">filename.html" to the end of the command.

Unix tools rarely have options to specify output filenames. They are as unnecessary as a button in a web browser that will let you "Display this webpage." Displaying webpages is what a web browser does, and writing output to a file is what a unix command does. It's just that the default file for a unix command is your terminal. Your shell makes it dead simple to pick a different one if that's what you want.

On my laptop, to view something while offline. On a server, to install something that is not in a package manager.

On that note, sites that don't easily offer copyable links for download annoys me to no end.

Most of the time downloading anything, I need it on another machine, and normally the easiest way is copy/pasting an URL from my local web browser to a remote terminal, and fetch it using wget. In which case an auto redirect to a mirror selector that again auto downloads the item, all handled by javascript, is pretty frustrating.

There's a fix for that!

Firefox has: https://addons.mozilla.org/en-US/firefox/addon/cliget/

and it's sorta built-in on chrome: https://coderwall.com/p/-fdgoq/chrome-developer-tools-adds-c...

I noticed this with mega.co.nz and I hate it, they do all the downloading with javascript then start an actual browser download (which is just copying from localstorage to your download directory) which finishes in an instant but I have to remain on the page now.

I don't think it would be possible to use curl for mega because it has to locally decrypt the stream first. I do remember using a (now deprecated) python library that wrapped the mega api [0] a while ago, so that might interest you if you want to do everything from the command line.

[0] https://github.com/richardasaurus/mega.py

With Mega it's rather unavoidable as the javascript is running the decryption.

You must understand that I live and breath in the terminal. If I'm working, my computer has at least one terminal window open.

When I'm in the middle of projects, there are several terminals, all on different 'machines' (ssh/chroot/and now docker) in different directories, and I need a file, be it source code or a binary or an rpm/deb/tgz/zip or just plain data to be where I am right now. I might use scp for this purpose, I might use rsync if the connection is flakey. Some times there's a shared file server and I can just use 'cp' instead.

Http is just yet another protocol where files come from, and when I use curl/wget I don't want the file in ~/Downloads along with all the other random crap, I want that it downloaded to where my terminal window is pointed, which may be a machine half-way around the world from me, or at the very least, in the right directory.

It doesn't make sense to download it to my machine, then upload it to where it needs to go either - just wget it directly, on the machine it needs to be on, in the directory where it needs to go.

I used to deal with shitty, unreliable internet all of the time (oh wait, I still do, I have TWC...), so wget was really useful for ensuring that I could keep documentation and other reading material handy when I inevitably lost my connection. Point it at the base URL, tell it to recursively download the whole thing, and within minutes you've got a complete mirror of the static site of your choosing, with the URLs patched up to point to local content and everything.

I often play around with new languages and other software that isn't in my distro's repo. For that, when they have a .deb available, it's often downloadable, and if I'm just playing around, I don't want to mess with my sources. So I copy the URL in my browser on my local machine, and paste it after "wget " in my terminal on the server, and go from there.

I could obviously just use curl for this, but wget requires no additional options or thought.

All the browsers I've tried have a shitty UI. It's faster for me to copy-pasta an URL into the terminal than it is for me to wait for the stupid download dialog to pop up, click save as, then use that silly widget to navigate to the path I likely already have as the cwd in my shell.

I have a bad connection, so it's better for me to use a download manager that can resume failed downloads properly. Browsers usually fail at that.