Earlier quoted context omitted.
"I'm glad I typed `man wget` instead of `wget --help`" -- no one ever You want the `wget --help` text over the man page, 99% of the time. The other 1%, you want the full info manual. The man page is an awful mix between the two; too dense for scanning through for the flag you need, but not containing the full information when you need specifics.
> no one ever Except [at least] me. I like man better because it's consistent. Some tools want --help, -help, -h, -H, -\? etc. I like man better because I can search it. I like man better because it gives me the details, not just a list.
Curl vs. Wget
51–60 of 205 posts
Re: Curl vs. Wget
#52Earlier quoted context omitted.
That's true of running just about any command-line tool on Windows. We were promised an ecosystem of Powershell modlets that operate on objects rather than text, but that hasn't really happened.
Any time I'm critical of Windows treatment of CLIs, I'm either met with "Why would I need a CLI, it's not the 80s" or "PowerShell is vastly superior to bash". The issue keeping the MS world from adopting adequate text only tools seems to be much more related to developer mindset than anything technical.
Re: Curl vs. Wget
#53Re: Curl vs. Wget
#54You should all check out wpull!
Re: Curl vs. Wget
#55Earlier quoted context omitted.
> no one ever Except [at least] me. I like man better because it's consistent. Some tools want --help, -help, -h, -H, -\? etc. I like man better because I can search it. I like man better because it gives me the details, not just a list.
For all of the reasons you gave (except search--that's what grep is for), I usually reach for `man`. But, for wget the information density of the man page is just wrong. At least these days it has some more information in it--it used to just be a reformatted version of the --help text, plugged into a generic template.
Plus even if grep matched something you can't read the context without extra options.
man is much easier than doing all that, but the time you have your full search command you would have already gotten your info from man.
Re: Curl vs. Wget
#56Re: Curl vs. Wget
#57Everything 6 years old is new again: https://news.ycombinator.com/item?id=1241479
Re: Curl vs. Wget
#58Also 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
Also amazing: jq.
Re: Curl vs. Wget
#59> Wget supports the Public Suffix List for handling cookie domains, curl does not.
This is outdated info. (lib)curl can be built with libpsl support since 7.46.0.
Re: Curl vs. Wget
#60Earlier quoted context omitted.
It may be more unix-y, but it's less user-friendly if the expectation is to just download a file. EDIT: Wow, surprised by the downvotes. I don't think I said anything controversial (y'know principle of least surprise and all), but maybe I was being a bit too opaque: wget , by virtue of being the first on the scene, built an expectation that $THING_THAT_GETS_URLS would result in a file without any other input/argument…
Remove your edit, it makes it more likely for you to get downvotes, not less. If you post something, stand by it, do not worry about downvotes. I don't really like them, but nevertheless I'm proud when I get a downvote - it means I don't have a hive-mind mentality.