curl command line option re-organization suggestion

[Ladar Levison]

Hi, I noticed the comment on the curl roadmap
[https://curl.haxx.se/dev/roadmap.html], about a desire to improve the
organization of the cli options, and had a couple of suggestions. The
first is simple... start hiding some of the more obscure/unused options
from the standard "-h|--help" output, and only show them if "--verbose"
is provided in addition to "-h|--help". That paradigm has grown
relatively common. My second, and more radical suggestion is to also
start building protocol specific binaries, when compiling curl/libcurl.
For example, 'curl-http' 'curl-smtp' 'curl-imap' 'curl-sftp' 'curl-scp'
etc, could all be added to the default configuration options. Precisely
which targets are added would depend on which protocols are
enabled/disabled, and supported by the release. I use the word "compile"
loosely, as what I really mean is the build process should create
hard/symbolic links back to the full curl binary (or create a full copy
if absolutely necessary), and these doppelgangers could then use the
executable name to print more relevant, and detailed help, along with
additional, and, or advanced command line options related and relevant
to the protocol associated with the executable. Again, this idea isn't
anything new. Bzip2, et al, jump to mind , and of course, busy box is
the champion of this strategy. I'd go one step further and suggest that
you give distro/package maintainers the option of also creating
executables without the "curl" prefix, which might make sense on systems
without an existing protocol handler, (scp,/sftp for example). L~

[Daniel Stenberg]

start hiding some of the more obscure/unused options from the standard
"-h|--help" output, and only show them if "--verbose" is provided in
addition to "-h|--help". That paradigm has grown relatively common.

This sounds like a pretty good option to me. The downside might be that it
only offers two levels and it's going to be hard to draw the line there and
decide on which side each option ends up...

An alternative would be to offer --help2 and --help3 etc... Or even
--help-http, --help-ftp and --help-all ... (I think I prefer this last one)

start building protocol specific binaries, when compiling curl/libcurl.
For example, 'curl-http' 'curl-smtp' 'curl-imap' 'curl-sftp' 'curl-scp'

...

these doppelgangers could then use the executable name to print more
relevant, and detailed help, along with additional, and, or advanced command
line options related and relevant to the protocol associated with the
executable.

Using this approach solely for the purpose of hiding some options from the
--help list seems a bit of a stretch I think...