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: Ray Satiro via curl-users <curl-users_at_lists.haxx.se>
Date: Sun, 13 Mar 2022 15:27:41 -0400
On 3/11/2022 4:38 AM, Daniel Stenberg via curl-users wrote:
> Over on Twitter, Leah Neukirchen brought an interesting idea for curl
> command line options.
>
> We have basically run out of single-letter options (practically
> speaking only -W, -5, -7, -8, -9 are left usused), making all new
> options forced to be long versions only. Like the newly introduced
> --remove-on-error [1].
>
> The proposal is that we "repurpose" using *two* boolean single-letter
> options and give them a unique meaning. For example, we can make "-ff"
> to mean something, or "-ss", "-aa" etc.
>
> Using this method we could make -ff equal to --remove-on-error while
> still having -f mean --fail.
>
> There is for sure a small set of users somewhere that use "-ff"
> already, that now are just setting --fail twice, and those would be
> negatively affected by such a change.
>
> Another, maybe slightly uglier but safer as it wouldn't risk any
> existing duplicate option using users, way to introduce two-letter
> options is to use one of the currently unused characters. -f9 could be
> made to mean --remove-on-error. The use of an adjacent '9' could then
> be used to extend any single-letter option to make a two-letter
> option. Or we could prefix it with a '9' and make a new family of ~60
> available two-letter options like '-9f' (and '9' here could of course
> be 'W' instead etc).
It's confusing and I don't like it. I think all future options should be
long --options. I also don't like the alias idea that looks like a bunch
of short options --roe (for --remove-on-error) either. I prefer long
options in scripts because it makes it easier to figure out what's
happening. Frequent options like -k -X -v etc are useful if I'm typing
in to the command line but now that we're out of them I think we should
leave it alone.
Date: Sun, 13 Mar 2022 15:27:41 -0400
On 3/11/2022 4:38 AM, Daniel Stenberg via curl-users wrote:
> Over on Twitter, Leah Neukirchen brought an interesting idea for curl
> command line options.
>
> We have basically run out of single-letter options (practically
> speaking only -W, -5, -7, -8, -9 are left usused), making all new
> options forced to be long versions only. Like the newly introduced
> --remove-on-error [1].
>
> The proposal is that we "repurpose" using *two* boolean single-letter
> options and give them a unique meaning. For example, we can make "-ff"
> to mean something, or "-ss", "-aa" etc.
>
> Using this method we could make -ff equal to --remove-on-error while
> still having -f mean --fail.
>
> There is for sure a small set of users somewhere that use "-ff"
> already, that now are just setting --fail twice, and those would be
> negatively affected by such a change.
>
> Another, maybe slightly uglier but safer as it wouldn't risk any
> existing duplicate option using users, way to introduce two-letter
> options is to use one of the currently unused characters. -f9 could be
> made to mean --remove-on-error. The use of an adjacent '9' could then
> be used to extend any single-letter option to make a two-letter
> option. Or we could prefix it with a '9' and make a new family of ~60
> available two-letter options like '-9f' (and '9' here could of course
> be 'W' instead etc).
It's confusing and I don't like it. I think all future options should be
long --options. I also don't like the alias idea that looks like a bunch
of short options --roe (for --remove-on-error) either. I prefer long
options in scripts because it makes it easier to figure out what's
happening. Frequent options like -k -X -v etc are useful if I'm typing
in to the command line but now that we're out of them I think we should
leave it alone.
-- Unsubscribe: https://lists.haxx.se/listinfo/curl-users Etiquette: https://curl.haxx.se/mail/etiquette.htmlReceived on 2022-03-13