Buy commercial curl support from WolfSSL. We help you work
out your issues, debug your libcurl applications, use the API, port to new
platforms, add new features and more. With a team lead by the curl founder
himself.
Re: Two-letter options?
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Timothe Litt <litt_at_acm.org>
Date: Fri, 11 Mar 2022 08:34:58 -0500
On 11-Mar-22 08:06, Jeremy Nicoll via curl-users wrote:
> On Fri, 11 Mar 2022, at 12:34, Rainer Canavan via curl-users wrote:
>
>> I do like Timothe's suggestion to expand completion.pl to cover bash, and such
>> shortened options may unnecessarily clutter the output with redundant notations
>> of the same options when pressing <tab> twice.
> Forgive my ignorance but is completion.pl part of curl? If not, it's surely a side
> issue?
As I noted, it's in the scripts/ directory of the curl tree. It's not a
side issue in that it's an alternative way to make typing curl commands
easier/faster.
> In my view whatever's decided on should not be done on the basis that some/many
> users use bash (or any other command interpreter that offers completion). Some of
> us are on platforms with no built-in command completion ...
curl isn't everything to everyone, much as it tries to be. If a
significant part of the user community benefits, then it should be
considered. Otherwise curl devolves to the least common denominator.
There are platforms that don't support IPv6 - that doesn't mean curl
should ignore them. It also doesn't mean that it should require IPv6.
Or any other feature - that's why there are so many build options.
Short command line options have their place. When they get too cryptic,
there's a usability trade-off. For the most expert/frequent user, they
save time. For others, they can be confusing and have unexpected
results. The proposals for extended short options that look like
bundled options is ripe for confusion. Shorter long-form aliases less
so, but they certainly add clutter.
My point was that there is another investment that can benefit both
groups of users. They're not mutually exclusive.
FWIW: I used (and developed) many platforms without completion for many
years - and liked them. Some allow abbreviating options to uniquess;
some have aliases; some have short for syntax like unix shells; some do
stranger things.
I did not suggest excluding platforms without completion. But for those
that do, why not take advantage of it?
In the case of shell completion, there's no cost to the curl tool aside
from generating the completion script. (Unlike, for example, TOPS-20
where your program is directly involved.) So there's only upside - it
doesn't drag any platform or user group down.
Timothe Litt
ACM Distinguished Engineer
--------------------------
This communication may not represent the ACM or my employer's views,
if any, on the matters discussed.
Received on 2022-03-11
Date: Fri, 11 Mar 2022 08:34:58 -0500
On 11-Mar-22 08:06, Jeremy Nicoll via curl-users wrote:
> On Fri, 11 Mar 2022, at 12:34, Rainer Canavan via curl-users wrote:
>
>> I do like Timothe's suggestion to expand completion.pl to cover bash, and such
>> shortened options may unnecessarily clutter the output with redundant notations
>> of the same options when pressing <tab> twice.
> Forgive my ignorance but is completion.pl part of curl? If not, it's surely a side
> issue?
As I noted, it's in the scripts/ directory of the curl tree. It's not a
side issue in that it's an alternative way to make typing curl commands
easier/faster.
> In my view whatever's decided on should not be done on the basis that some/many
> users use bash (or any other command interpreter that offers completion). Some of
> us are on platforms with no built-in command completion ...
curl isn't everything to everyone, much as it tries to be. If a
significant part of the user community benefits, then it should be
considered. Otherwise curl devolves to the least common denominator.
There are platforms that don't support IPv6 - that doesn't mean curl
should ignore them. It also doesn't mean that it should require IPv6.
Or any other feature - that's why there are so many build options.
Short command line options have their place. When they get too cryptic,
there's a usability trade-off. For the most expert/frequent user, they
save time. For others, they can be confusing and have unexpected
results. The proposals for extended short options that look like
bundled options is ripe for confusion. Shorter long-form aliases less
so, but they certainly add clutter.
My point was that there is another investment that can benefit both
groups of users. They're not mutually exclusive.
FWIW: I used (and developed) many platforms without completion for many
years - and liked them. Some allow abbreviating options to uniquess;
some have aliases; some have short for syntax like unix shells; some do
stranger things.
I did not suggest excluding platforms without completion. But for those
that do, why not take advantage of it?
In the case of shell completion, there's no cost to the curl tool aside
from generating the completion script. (Unlike, for example, TOPS-20
where your program is directly involved.) So there's only upside - it
doesn't drag any platform or user group down.
Timothe Litt
ACM Distinguished Engineer
--------------------------
This communication may not represent the ACM or my employer's views,
if any, on the matters discussed.
-- Unsubscribe: https://lists.haxx.se/listinfo/curl-users Etiquette: https://curl.haxx.se/mail/etiquette.html
- application/pgp-signature attachment: OpenPGP digital signature