curl command line option re-organization suggestion
Date: Sun, 26 Aug 2018 21:22:30 -0500
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~