Lets compare the length of the man page:

    $ man curl | wc -l
    1728
    $ man wget | wc -l
    1096

How about the --help output?

    $ curl --help | wc -l
    178
    $ wget --help | wc -l
    176

The wget help is nicer, grouping options together by category and with longer text. curl just has a long list of options in alphabetical order. How many (long) options do they have?

    $ curl --help | grep -- -- | wc -l
    175
    $ wget --help | grep -- -- | wc -l
    137

I'd say it is a lot quicker to work out the flags etc you need with wget because there is less to look through.

"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.

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.

grep on help output is annoying sometimes since many programs send it on stderr and you need to redirect it if you want to pipe it to grep.

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.

|& is useful in these cases, as it redirects both stdout and stderr to the piped process's stdin. It's a cshism, but it works in both zsh and modern bash. Much nicer than typing cmd 2>&1 | cmd.

For context try grep -2, where 2 is the desired lines of context.

  $ wget --help |& grep -2 base   
    -i,  --input-file=FILE           download URLs found in local or external FILE
    -F,  --force-html                treat input file as HTML
    -B,  --base=URL                  resolves HTML input-file links (-i -F)
                                       relative to URL
         --config=FILE               specify config file to use
  --
                                       existing files (overwriting them)
    -c,  --continue                  resume getting a partially-downloaded file
         --start-pos=OFFSET          start downloading from zero-based position OFFSET
         --progress=TYPE             select progress gauge type
         --show-progress             display the progress bar in any verbosity mode

(Not that I'm arguing that this is an excuse for wget's [and GNU projects' in general] man pages sucking, but it's a useful workaround.)

I know how to do it, that's not the question.

But rather, doing all that seems easier than man to you?

I really wish the GNU foundation would give up on info pages. Just admit failure and condense them down into full info manpages that I can search easily instead of having to use their 1980s version of a web browser with its awful EMACS-like keybinds.

I recommend using this script[1] and aliasing it to "man". Saves so much time over loading man pages and searching through them. For example, with it aliased to "man", you can run "man wget continue" or "man find -exec" and get just the relevant parts of the man page. And "man git commit -a" also works, despite the separated command name.

1: https://gist.github.com/alphapapa/3cba3ff196147ad42bac

> help is nicer, grouping options together by category ... vs ... long list of options in alphabetical order.

Honestly, either is good. Grouping options is good if you don't know what you're looking for, and alphabetical is good if you do. The bad ones are like the help page for rsync - a ton of options, with no semantic ordering at all.

I don't think you can:

"[Wget's] ability to recover from a prematurely broken transfer and continue downloading has no counterpart in curl."

    curl -C - -O filename url

-C continues from an offset; "-C -" uses the length of the output file as the offset.

That's what I tried a couple years ago and it failed. Might try it again some time.

I guess it's possible that the server didn't support HTTP byte serving via Accept-Ranges:, either for that particular resource or altogether.